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=FGqk5APB; 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=yZi2MMdT; 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 4A0593F80C for ; Tue, 21 Jan 2025 15:47:43 +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=aTJofVy4Kz85QTU/vlN42WcyXsCr1b5IiND2IYgQM7s=; b=FGqk5APBxduwnO6jRKHeE7rql00wtNbfaKDPD9CqUqDUTzOTf1ATanDp fIM5CFaeb/B1ZyJpX1FndnbgfKZ936rB7eQgkCdBmi0ha+0+YHSpdpmjq P/+mD1Pj00D9oYd9HyBED4lDd8sf+gkBFHXWqo1yUdAUVl9AugiY3brVU M=; 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,222,1732575600"; d="scan'208,217";a="204259981" Received: from prod-listesu18.inria.fr (HELO sympa.inria.fr) ([128.93.162.160]) by mail2-relais-roc.national.inria.fr with ESMTP; 21 Jan 2025 16:47:42 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id 1DC82E0D1E; Tue, 21 Jan 2025 16:47:42 +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 53A58E0077 for ; Tue, 21 Jan 2025 16:47:35 +0100 (CET) IronPort-SDR: 678fc192_+S+HCQWSUXDKpN1kyRNaZn2FIG+vmbCVJCRGRE03Fa3D9yp 4zBRYhosjFYidhycVpLvSsMtLQkcBebMyCS8fMQ== X-IPAS-Result: =?us-ascii?q?A0G+IgCmwI9ngSIeaIFQChaCSIE/WygZAWNaMwcISAOEU?= =?us-ascii?q?4FjgWyOIIEWiHyHO4FUhnSCMIFqgREDGBYjFAEDAQ0uAQUMAQECBAEBAwECA?= =?us-ascii?q?YIMgT1xQAQCAop0Ah8GAQQ0EwECBAEBAQEDAgMBAQEBAQEQAQEFAQEBAgEBA?= =?us-ascii?q?gQGAQIQAQE9BUmFew1JAQEBAwEKAQQBgWVRUx5eBwkGAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEiAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QIIBAEHBQYHFwMrJBoCAQIGChMBASYBAQEBAQUCAgQYIwMJCwEGAwIRATUDA?= =?us-ascii?q?RMBEhQCAwEBgg4URYIfRQMFDAY/lmmbFCcQeoEygQGCDAEBBoEIPgIBAQEJA?= =?us-ascii?q?gIDAQ4JJQHaBoFkCYEwGAGFaoJJGgEqSGoChEgJhDECJw+BVUSBFAE1gVYdE?= =?us-ascii?q?jgHb4FBfgsXAQEBAQEXRDsIAQkBBwQGAgECBAIJCQ8REwkJgxyCaYIfF0tFN?= =?us-ascii?q?X1bLF57EYFshGcSTwWBQR5agR+BOx0dJQpGgQ83HQh7LIFbgws+BAQSWQOIJ?= =?us-ascii?q?4FHSzMsAVUTFwsHBWGBEAMtNjGBSXs5gg1pSToCDQI1gh4kWIIrgx2BPYRFh?= =?us-ascii?q?FGFXoIUghGEch1AAwttPTcUG5wmCTU2ATyCbRAFARoLDgoBFBkCBAEBEhcDE?= =?us-ascii?q?AMXAQkCBwoHBAoFAQUCAwkICgQBAQkHEAItAQMBBAUJFQoHBQcDGAERBgIEC?= =?us-ascii?q?QQBBQQECAUEAQIDAQEBAgEKAQwDCQYFAwECAgMGAgYBFREDhF2NYAgKAhIIC?= =?us-ascii?q?gEDBAEBJHeOUIsngmuTUx1tNAeEHoFdBgyIHGmBJIJYiz+EDYNXhASBV4U7h?= =?us-ascii?q?XQDhn2SSSKYWiKCNoJ4gy2BAApTQwUJgW8eTIELhBICgUhwgRwSjBIQFhMDB?= =?us-ascii?q?AQLDQECEGiBKYMSgX4hAjwNIz8BARkDDAczGjBDDQoEB4IRAQEBMQkKPBwPV?= =?us-ascii?q?4dKhV4tARaBDAEBBgGBZVgGECMOOgY9gRgDC4F1FyRaIYEXVAe1HgJCNQIBA?= =?us-ascii?q?QoFKQIHAQoBAQMJhWIBAYMEghdugwhZAiYHBWsDVQgBAQ?= IronPort-PHdr: A9a23:4FTWrxV5MD39b8rMKNDq3q7e2azV8KzOWDF92vMcY1JmTK2v8tzYM VDF4r011RmVBtydsq0ewLaH+4nbGkU+or+580o+OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF 95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRoLerpBIHSk9631+ev8JHPfglEnjWwbL1vI BmssAnctNcajYRtJ6s11xDEvmZGd+NKyGxnIl6egwzy6sCs8pB97i9eoegh98lOUaX7e6Q3U 7lVByk4Pm42+cPmqwDNQROA6XUAXGoWlAFIAxXe4xHhQpjxqCr6ufFj1yScIMb7UKo7WTWm7 6dsVR/olCIKPCM3/W3LlsB9ir9QrxW8qRxi2I7UeJ+aO+Zifq3TetMaQHBOXsdXVydcBo+xY I8CA+8HMO1FrYfyukEOoAO+CweyGe3hxDxGiXDq0qAhyestDRvL0RY8E94SsnnZqsj+OqcIU eCyyanF1SnOb/dM1jf79YPGbwwuofGJXbJxbcrR1VQkGgTfgVWUs4PlOSmZ1v8RvGib6upgV P6vi3I8pgFppTivwsctipXXiY0JylDE8yR5wJ8oJdKmUkJ7ZsSkEJRJuiycKoB5Td8sTXtyt yYm1r0Jp4S7fC4SxZkn2RLSav2KfoqH7x79VeudPCp0iW95dL6hhhu/8kmtxOLgW8S10FhGs yVLnsTRu34C1xLe6ciKR+V/80u/xzqC0R3Y5O9DIUAxj6XbKpghz6YolpUNrUTDHzP2l1vuj K+Rc0Uk//an5/7hYrr4up+QL4h0hR3kPaQrnsyzG+M4MhIBX2SD/uSzyKfs/Uj9QLlTlf02n LPVsJfAJcQUvqK4DQ5V0oUi6xanETipzdUYkmMdIFJCYhKHgJDlNEvOIPDiE/i/jU+snC13y PDBO73tGpfNIWLFkLj/ZrZ991RcxxQtwtBD/Z5bFrYBIPfrVk/tqtPZDxg5Mxeuz+n7D9V90 5sSVnmLAq+eN6PStESH6fw1I+mDfoMapDH9K/096/7qk3A4ll4dfaeo3ZcNdH+4GfFmL12CY Xrth9cODWAKvhAmTODwlFKCVjtTa263X6I9+jE7E5+mApzCRoC2gLyB3Tm0HplIaW9aFlCMC 3boeJmdV/cWdC2dPNVtnSIZVbS5V48uzwuutA7nxLV5NerY4DEXtZXm1NRt+u3TkxAy9D1uA MSHyW2CUXp0knsNRzAowq9/vVF9yk+Z3adkhPxYEMRf5/JPUgcgNJ7T1fZ2C97oWg7ZYtiJT 1CmQtu4DjE3QdIxwtkObFhnF9q+iRDD2jKmA7AUl7yXBJw077nT02LtKMZ6znbKzLMhj149T ctSL22qnLJw9w/UB47Ri0mZkrildaAG0y7L+2eM03CCvFtGXwJoVqXKQWoQZk7Srdjj/E/CS KWuCbs/PgRd08GCL7FGZcf1gllcWffjO8zSYmK2m2etGRaI26iDY5Twd2oB2yXdDVAIkw8S/ XaaNQg+Gzyur3jEADNyElLvZlvg8e1/qHOiU080zhyFb1Zm17Wv4h4Zn/2cS/Ud3rIDoCshp DN0HEun09LREdqAqBJtfKpdYdMh4FdHyHnWuxZ8PpynN6xig0ARcwBvv0z0zRl3DZ9Akccyo HM0zQpyMr+Y30lFdzODwZDwJ6DYKmj1/By1d6HW3VTe3M6Z+qcV9vs3tVPjvAGuFko/6HVoz cNZ03qb5pnSDQsSVpXxUkMt+xhnvLHWeiY954TT1X1jNam7rCXO1M4uBOsg0hqvYspfMKWaG wPoCMIaGsmuKOg3lFSxYBIEIeZS+LczP8y6bfSG3aqrMPx8kzKhiGRL+Jxy0kOW+yZmV+HHw YgFzveF1QWETzfxlEqtvt7zlIxeeD0eAmWyxTLqCYJNfKF/c4kGBX+zL8C529lynYDhVn5X+ VK5GV8KxdWldQSdYlH52wBbyFoaoXi6mSuj0zx7jSspoLee3C3P3evvbAYLN2hWT2d4l1jsO 5K7j9UCUUiocQcpkByl6F7/x6lUuahzNXHTQUBMfyn2M2FtTLe/trqEY85O8ZMorDtYXP67Y VCARb7xuxoa0yX9EGtC3D03ai+mt5HjkxBnlG6QI2x/oXTFdc1qyxrS68TQRftL0ToHQCl4h yPXBl+5P9Sx4Nuai4rNvvymWm2uUZ1fbyjkwJuOuyWj/WBqGRq/n/Szm937Dwc1zS/7199rV SXRsRbzfJPn16OgMeJoZkRnHlv85NB8Go1kiYs/mJEQ2X0bhpWJ4XoKinz8MdJG2aL4cHUCW yULz8TQ4AXq10xvNHWJx5j2VnmFxMtufMG1YnkK1SIl88BKFKCU4aRZkSdtuFq3sRrRYeRhn jca0fYh9GQVg+QNuAY0yiWdA6sSHVVDMCz3lxWI6si+o79NaGaud7iwzkt+ksq7ALGMuAEPE Er+L90mAik6ppF7L1Tk1GL1rIfpZI+UJdkasxnRlxbbk8BULogwn7wEn3lJI2X46FQhwuhzt hdu2JCmoMDTImFk+uSiCR5dNyHpT9sU/iDxgK1emMePwo3pGY9uTGZYFKD0RO6lRWpB/c/sM ByDRWFtwp/6Mb/WHAvErVxjs2qKCJezcXeeOHgey9xmAhibPk1Wxg4OD30hhpBsMAesyYT6d VthoCgL7wvxrhJKjPljNxz+Tnv3vACseys5Q5iZLQNL40dF/UiGedeG4LdLFjpDtoaksBTLL 2WaYwpSCmRcYXa/XwXdOeOesOTmpvCfAvuiIvDOZ7SXtOEYUO2HkJur240g5D2MM8STIlFoC OA90UdYG3UlC4LegTpcAzcPmXf1ZtWA7Ay55jUxrs2796HzXxnz4IKUF7ZIGdB/olauhqOSK +ObhCB4MCtVkJQWyhck0ZA521gfw2FrfjipSvEbsDLVCbnXgulRBgIabCV6MI1J6bg9109DI 5yTjNS9zbN+gvMvbjUNHVX8hsGkY9ALKGChJRvGAkiMLrGPOTzMxYn+f6q9TbRaiOgcuQe3v H6XFErqPzLLkDeMNVjnOOVFimeANxxbuZ2hWg5qDXn/QdnmbByiLdIxiic5gPU1in7MKW8AI G1kaUoey9/YpShcg/h5BylA9i88d7jCwn7FqbKAbM1K4p4JSmxumulX4Wo30e5Q5SBAH7lun TfK68Vpuxegm/WOzTxuVFxPrCxKjcSFpxYHW+2R+59eVHLD5B9I43+XDkFAnOFeUojRvPpgn +Xpwbr0LCZe/tnU+8oFGsWSL9iIZXMlOByvAzXUCQoZURahMnzZjEFG1vTO5juStJdw+f2O0 NIeD6RWUlA4DKZQA0BsGpoZK5dyXy84uaaciN8U6HG+qhjIWcgcuYrIHKH3Y72nOHOSir9KY AENyLXzINEIN4H17Edlb0FzgIXAH0e4scllmiR6dUd0pUxM9CM7VWgvwwf+bRvr5nYPFPmyl xpwiw1kYO1r+i2+q1swI1PLomM3nixT0Z3euwvJJQD2dpflYKcDEy3wplQ8OZP9Qh9oYEu1h 0MxPTPNQfRKhLtldHx3oAXbpJ1EFOUaSPFUJhgKypT1L70k3E9dpSOu2UJcrbKfWN07zFdsK sbq9C4I0hkrdNMvIK3MOKdFhkNdgK6DpG7NtKh5wQMTIVoM7HLHfScJvEISMbx1byGs/+Fq9 UmDg24aIjlKDqJ25KkysBhhaIHih2r63rVOK168LbmaJqKd4C3bkNKQB0g3zgUOnlVE+r5/1 YEidVCVXgYh1uj0dVxBOMzcJAVSd8cX+mLUeHPEit/2mcdLON+NQ93OGPeJsLcIj0mkGgcwA olK6d4OS5Co2UeeNsznKb8Z1T0n4xntL1ieSvEVaFSMijhN8KTdhNdnmJJQID0QGzA3Ch+Mv uPpoVUa1celCc8xZmYGU4AEMHMvRcD8nDRW6n1EBT/xyekZzQme8xf2oTnWBzTnKd8/dLGTf xwmW7TUsX0vtqOxj1DQ6JDXIWr3YM9jttH44uQfv5+bCvlQQOo1owLGloJfXXDvT3/XHIv/O c3rc4d1J4+RaD7yQhmlhjkyVcu0INu9Mv3Cn1TzXYgN+MqaxGxxbJXsUGhGR1Er/6dYuOo/Z BVfMcNhMFix71h4bPT5e1r9sJ3mAGe1dWkHFr8Gl7z8OeYRlnJzJqy70CVyFMlilrvrqEJVF phY0RjTmKTxOYUBAXqoQRk/M02MpDJnxTI5br9gnr4zmEGR4whAPz3ZJrMyNmAW4I1jXRvXK HFyQALUXnekhJHYqk6p1rEWpG5GmspMlPZCqD74t4PeZzSlXOqqr4/Uumwud4pur6p0OI3la syI0fGW1iTYV4XVuxaZXTSSEuoD3MBXJDNETfJIn2A8JMFAvpBOoUY8TcYxIbVTBbJk/+r7L 2M8UWhJlWlCC8uJx1lgyq+k1qHflwuMfZhqKxECvJhYw5McXyNwfiICtfqjWoHRxCePTmkGJ htW7BwZvVhR0NYoIqa+uMyTEMwpqXYeuf9/XyrVG4M98lL6TjrTml3kULC6lPTv2wtOzfXq2 91dWRhlCEEbyfwF8ylgYLxxNaQUuZbH9zGSckav9lnX87PzGl4L+ZjpUQjgC47UqWf3Uisd4 GAZA4hVxyTWEZ0U1RFyaKMquElkKoe7fE3z/Hohm5QvGKO3H5POpR5tvTMdSiGmHsAUQflhq 07SUSZ5boqDrYW8fY1VRn5M9ZadrVZAjUgrNDS2g8k5SYkF8nsHWz5Bpi+Ytd25RZhY2MN4O JQLJ892p3b3HK4XcIjUuXA9vabjj2PI4z1p+knv3y29QuXrKoARt31bAAgiIH6S71UiH/d5u HmH6UjD6xh9t6JSArzF5a2UiC56GoFSCz1J03G8Mlk1S2NJ4b0ywEv9ectBRfI/flmqZwx4E uQpjRXhFaBcmGegJTR1shpG9ivdWQgtSCRTha3iy2R2lw== IronPort-Data: A9a23:o6a0qqMNgRgVnSnvrR0Ik8FynXyQoLVcMsEvi/4bfWQNrUoigTQAm DNOCDjQPvuOZDP3fop+bYyyoRlVsJeGm4cxG3M5pCpnJ55ogZqcVI7Bdi8cHAvLc5adFBo/h yk6QoOdRCzhZiaE/n9BCpC48T8mk/vgqoPUUIbsIjp2SRJvVBAvgBdin/9RqoNziLBVOSvU0 T/Ji5OZYQTNNwJcaDpOtvra8ko35pwehRtB1rAATaAT1LPhvyJNZH4vDfnZB2f1RIBSAtm7S 47rpF1u1j6xE78FU7tJo56jGqE4aua60Tum1hK6b5Ofbi1q/UTe5EqU2M00Mi+7gx3R9zx4J U4kWZaYEW/FNYWU8AgRvoUx/4iT8sSq9ZeeSUVTv/B/wGXYakron69FAngSOL8i1PdvLmBpy cwHfWVlghCr34pawZq+WrAqnsMnPdXmN4MZu2h9wHfeF/lOrZLrGv+bo4YAgHFr3oYVQZ4yZ OJBAdZrRC/6WEUaBFBNOMcDurKwgX3ubzBTqFSUvLc6pW/Jw1l41LHrdsHeetmLWdl9lEGFo GnL5CL8XgFcM8aQodaA2iv02L6RxH2iBOr+EpWjxtpax1qT6lA2GRIoWl+6vMmGiW6HDoc3x 0s8oXdy8/NtrCRHVOLVVBS9pDuAvwUAc8FBFvUzrgCL0KvdpQiDblXoVRZEeIVgrMgyVCAn3 V+Pnsr0CHpoqrL9pW+hGqm8syqDPXRPBmE7QSo2dyUU+/bih70DkUeaJjp8K5KdgtrwEDD25 jmFqikimrke5fLnMY3gojgrZBr39vD0oh4J2+nBYo6yxi1DDLNJiqSt+QGd9fFEPZqURVmHv WEZlo6Z9u9m4XCxeM6lHr9l8FKBvqjt3NjgbbhHRMFJG9OFoS7LQGyoyGsiTHqFy+5dEdMTX GfduBlK+LhYN2awYKl8buqZUptxkvO5TIm/DqyMN7Kih6SdkifbrEmCgmbMgQjQfLQEysnTx L/FLJv3Ux7294w9lGTrLwvi7VPb7ntjmT2IGsiTI+WP3LGZYHPdUbABIUeDZeA/7bqZrU3Y6 81UL6O3J+Z3DYXDjt3s2ddLdzgidCFjbbiv8pw/SwJ2ClA3cI3XI6WAmet5E2Gk9owJ/tr1E oaVAxcClgGu3CCfc21nqBlLMdvSYHq2llpjVQREALpi8yFLjV+HvfZHJagkN6Iq7vJixvNSR vwIMZfISPdWRziNv3xXYZDhpcYwPF6mlCCfDRqDOTIfRp9HQxCW29nGegC0yjICIBDqvuQDo pqh9Djhf7w9eypYAv37Usmfl2GKgSBFmcZZfVf5Hd1ISUC9rKloM3PQi9E0EeEtKDLC5CSQj RbLDTgmp+Di/pc+wOfNoaXVvrW4MvBfG3BCFDLx9oeGNij9/0uiz7RfUe2OQyvvaWPs9IimZ sRX1/vZMsBbrG1VsoF5Laln/Zg+6/TrubVe6AZuR1fPUHiGFZJiJSOg8fRUl6gQ2IJchxS6a niP9vZeJ7+NHsHvS3wVBQg9a9W8xeMmoSbT4ds1MXfFyndOppTfanprPj6IlCB5B5l2Otl8w e4e5egn2zbmgR8uatu7niRY8lqXFUM5UoIli4o7BbH6gQ9623BAZp3hUhXN2q+tUOkVEEcWI W6zvpHg1pB83UvJdkQhGUfdhdR9gYs8gzEU7VsgCWnQpP/7qK4W5iBByRU2UQVf8Ttf2c1RJ GVAFhN4NIeOzRhSlelBWGGmKw5RIBuz5EbRzwM7q0veRUysRmDyEXA3YsSL3UEG8lBzeipQ0 6GYxV3EDxfrXpDV9QkjVXF1r8fMSYRKyTTDv8S8DeGpIoIfYwe5spSxZGENlQTrMfkxiGLDu +Nu2uR6Mo//CgI9vIw5DNO8+YkLaRXZOlFHf+5tzJkJEU7YZju2/zqEcGK1W8FVIs314V2KM NNvKu1PRiaB+n639B5DPpE1IphwgPINz/gBcOmyJWc57p2ungAwu5fUriXDlGsnRut1qvkEK 6TTSimjF1KBjn4Fik7Pq8h5YlCDW+cmXzGl/u6J87QuLakh4cVMakA514Wms0qFaDVH+w2mh yKdRqv04dE796FSsdrCLqFxCT+wC+vPb8WT0QXqs91xfdLFasjPkAUOq2jYBQddPJpPetFVi 7iy7dzF7GbYtooMD0TcyoizBohSxMCIROEMGNnGHHpbuiqjWcHX/BoI/V6jG6FJiN9w4sqGR ROyTcmNKe4uRNZWwUNKZxhkExoyD7r9aoHir3ifq8ugJwc80wudCv+a7l7sMH9mcxEXN63EC gPbv+ik4vZapt9uAD4GH/RXPI9qEmT8WKcJd8zDihfANzOG2mi9g7rFkQYszRrpCXPeScbz3 s/jdyjELR+3vPnF8cFdv4lMpSYoNXdag9QrX0cj6tVz2iGbDmkHELwnCq84KKpoyw786JKpQ wv2TjoSOX2oF3AMOxDx+8/qUQqjF/QDcIWxbCAg+0SPLTy6HsWcCb9m7T1t+GpyZiCl9uy8N NUC4TflC3BdGH2yqTo7vZRXQNuLx882AloN6Rm7i8v2EgoTCrUM1WV8EUxKTyOv/wTlihDQP WZsLYxbaBjTdKIzOZ8Il71p9NUxtjTyyT4ldmGKnMaZvJ+UpAGF4OOqIPn9i9Xvc+xTTIPjh hrLq6+l+2eSy2Aesqsvuss0jOlzE/3j8g1W6kP8bVV6opxcIVjL8y/PceTjgS3iFMNi/4vhq wSR IronPort-HdrOrdr: A9a23:4bLP7qo/n3HGQSidhCh3XDwaV5oWeYIsimQD101hICG9E/bo9P xG+c5w6faaslgssR0b9OxoW5PhfZq/z/9ICOAqVN/IYOCMggSVxe9ZgbfK8nnJJGnV9+JW16 tsGpIOauHYPBxdlsi/xAG5Fr8bsb26GU2T9ILj80s= X-Talos-CUID: 9a23:LBZ8d2Gzzl4m9ocmqmJ57X8QRpoOfET5yUXqDV6gJmdOdI2KHAo= X-Talos-MUID: =?us-ascii?q?9a23=3A59SZPQ2Oo1/1yYxu1gEvK/GMFjUj+JSKOAcKkbk?= =?us-ascii?q?6ntiLCyN0OiqtszeXe9py?= X-IronPort-Anti-Spam-Filtered: true X-URL-LookUp-ScanningError: 1 X-IronPort-AV: E=Sophos;i="6.13,222,1732575600"; d="scan'208,217";a="106961614" X-URL-ContentFilter: X-MGA-submission: =?us-ascii?q?MDH3+o2R2ZDnG0R/OjTnc7mtPgIbFc6swiJSCb?= =?us-ascii?q?klvtxFI4USm7+QbJSc6aebv0/6sL2LiwZu6tGvv3XpKgos5i5B+G6U3n?= =?us-ascii?q?fiYdtY0RkSW/kryBmmUjVs7rjrZ4QOZ9qE/3KxtooG/KeUprBJHuzmft?= =?us-ascii?q?Cna6GuDUVLi484/PFXWrcrQg=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; 21 Jan 2025 16:47:30 +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 D73175648C5; Tue, 21 Jan 2025 16:47:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=polytechnique.org; s=svoboda; t=1737474447; bh=Irm8fjAaojj8K9fBllzuD8/3T08nhhwM91XxhczPmIY=; h=From:To:Subject:Date:Message-ID; b=yZi2MMdTc8T23ZZ+nU69J6xubIjC3Vw8RxxZkHjBcKUY8YWwVsVcD2QUa5LAIHZku 9a6GyUrV23XAgHR87G8uQTSlh70apkLkj9lUUmYgPX/qhKmYSaTeAZh5gyNLS8RbUK KdW9ytIBxWUR3P6ne02urBa0ie6YCgPGuBYVsUKo= From: Alan Schmitt To: "lwn" , caml-list@inria.fr Date: Tue, 21 Jan 2025 16:47:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-=-=" X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Tue Jan 21 16:47:29 2025 +0100 (CET)) X-Spam-Flag: Unsure, tests=bogofilter, spamicity=0.499952, queueID=812035648C7 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: 19255 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 January 14 to 21, 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 OCaml Software Foundation: January 2025 update ppxlib.034.0 Release of Carton 1.0.0 and Cachet Opam repository archival, phase 2 - OCaml 4.08 is the lower bound Ocaml-posix 2.1.0 released! Release of ocaml-eglot 1.0.0 Semgrep is hiring to help scale their static analysis engine Dune dev meeting Tarides: 2024 in Review Other OCaml News Old CWN OCaml Software Foundation: January 2025 update =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=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 Happy new year! This is an update on recent works of the [OCaml Software Foundation], covering our 2024 actions =E2=80=93 the previous update was in [January 2= 024]. The OCaml Software Foundation is a non-profit foundation ([earlier thread]) that receives funding from [our industrial sponsors] each year, and tries its best to spend it to support and strengthen the OCaml ecosystem and community. The funding volume we receive each year is around 200K=E2=82=AC. (For comparison: this is the yearly cost of one experienced full-time software engineer in many parts of the world.) We do not fund people full-time for long periods. Most actions receive from 3K=E2=82=AC to 20K= =E2=82=AC. The work to prepare and execute actions is mostly done by the (unpaid) [Executive Committee]. It is currently formed by Nicol=C3=A1s Ojeda B=C3= =A4r, Damien Doligez, Xavier Leroy, Kim Nguy=E1=BB=85n, Virgile Prevosto and my= self, with administrative personnel provided by [INRIA] and general assistance by Alan Schmitt. Our current sponsors (thanks!) are [ahrefs], [Jane Street], [Tezos], [Bloomberg], [Lexifi], [SimCorp], [MERCE] and [Tarides]. (If your company would like to join as a sponsor, please [get in touch]. Unfortunately, we still cannot efficiently process small donations, so we are not calling for individual donations.) Feel free to use this thread for questions/suggestions :-) [OCaml Software Foundation] [January 2024] [earlier thread] [our industrial sponsors] [Executive Committee] [INRIA] [ahrefs] [Jane Street] [Tezos] [Bloomberg] [Lexifi] [SimCorp] [MERCE] [Tarides] [get in touch] Recent actions =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=97=8A Education and outreach We funded a new edition of the Spanish [summer school] on functional programming in OCaml, organized in Saragossa by Ricardo Rodriguez and Roberto Blanco. We continued funding the OCaml meetups in Paris and Toulouse, France. In 2024, a [new meetup] started in Chennai, India (first [discuss thread]), which we are delighted to support as well. We are sponsoring the [JFLA 2025], a functional programming conference in France, and an [OCaml Bridge Workshop] at Functional Conf 2025, a large Asian conference on functional programming. [summer school] [new meetup] [discuss thread] [JFLA 2025] [OCaml Bridge Workshop] =E2=97=8A Research The OCaml Software Foundation is typically not involved in funding research, focusing on actions that have an immediate impact on the language and its community. Nevertheless, in 2023 we funded one year of post-doctoral work for Takafumi Saikawa in relation to his maintenance work on the type-checker of OCaml. In 2024 we funded one year of research engineer for the [Salto] project, building a static analyzer for OCaml, and one year of PhD grant for [Alistair O'Brien] in Cambridge (complementing other funding sources for a full PhD), continuing his [impressive work] on constraint-based type inference for OCaml. [Salto] [Alistair O'Brien] [impressive work] =E2=97=8A Ecosystem =E2=97=8A Infrastructure As in previous years, we fund the work of Kate Deplaix to check that the OCaml ecosystem is compatible with upcoming compiler releases; in 2024 Kate worked on OCaml 5.2 and 5.3. We are trying our best to support the work of opam-repository maintainers, through individual funding grants for the active maintainers. This year, on the suggestion of the repository maintainers, we are also funding the work of [Robur] to migrate unmaintained packages to a separate archive ([discuss thread 1], [thread 2]). [Robur] [discuss thread 1] [thread 2] =E2=97=8A Tools In 2024 we have funded one month of maintenance of the `opam' client by Raja Boujbel and her colleagues. We renewed our partial support for the work of Antonio Monteiro on [Melange]. For more Melange news, see for example the announcement of [Melange 4]. [Melange] [Melange 4] =E2=97=8A Libraries We keep supporting the work of Petter Urkedal on the [Caqti] library, the main database connection library in the OCaml community. The [Owl] library for scientific computing has been [restructuring] in 2024, with its two maintainers moving to permanent jobs demanding their time and therefore less available. The OCaml Software Foundation is providing a small grant to help the maintainers transition to a different contribution model and/or preserve a part of their maintenance activity, as they think is best. We have been funding documentation work by John Whitington to collect or create usage examples of important OCaml libraries, prior to their upstreaming in the documentation of each project. See his [ocaml-nursery] repository. We support the contributions of Daniel B=C3=BCnzli to the OCaml ecosystem. This year, Daniel used this support to fund the development of =E2=80=A2 [jsont], a new library for declarative JSON data manipulation =E2=80=A2 [bytesrw], a library of composable byte stream readers and wr= ites, with support for various compression and hashing algorithms =E2=80=A2 [support] for Unicode 16.0 in his Unicode libraries Finally, we have been funding Nathan Rebours to take an active part in the maintenance of the ppxlib project, see his [ppxlib maintenance summary]. [Caqti] [Owl] [restructuring] [ocaml-nursery] [jsont] [bytesrw] [support] [ppxlib maintenance summary] ppxlib.034.0 =E2=95=90=E2=95=90=E2=95=90=E2=95=90=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: Nathan Rebours 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 We're happy to announce that we just released ppxlib.0.34.0. The full patch notes are available on the release page [over here]. The main features are OCaml 5.3 compatibility, new AST pretty-printing utilities and the ppxlib-tools package, support for `[@@deriving ...]' on class types and the addition of missing `Pprintast' entry points. [over here] Changes summary =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=97=8A 5.3 compatibility ppxlib.0.34.0 is the first official ppxlib release that's compatible with the new 5.3 compiler. The ppxlib driver now also comes with a `-keywords' CLI option, similar to the compiler's that allow you to compile and preprocess with the 5.3 compiler code that uses `effect' as an identifier. This is pretty niche but it's there should you need it. Please note that means you can use ppx-es with a 5.3 compiler but not that ppx-es can consume/produce 5.3 language features. We're currently working on a fix allowing you to use the effect syntax in files that require preprocessing as it's not possible with 0.34.0. The fix should be released in the next few days as 0.34.1. =E2=97=8A AST pretty-printing We added a new `Pp_ast' module that allows you to pretty print AST fragments. The only way ppxlib would print ASTs before were as S-expressions. In practice we found that it was not always helpful and wanted a more readable and human friendly way of displaying the AST. The default output of those printer is a simplified version of the AST to keep things clear and avoid cluttering the output with information that is not always useful. For example, if you run `Ppxlib.Pp_ast.Default.expression' on the AST for `x + 2', you'll get the following: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 Pexp_apply =E2=94=82 ( Pexp_ident (Lident "+") =E2=94=82 , [ ( Nolabel, Pexp_ident (Lident "x")) =E2=94=82 ; ( Nolabel, Pexp_constant (Pconst_integer ( "2", None))) =E2=94=82 ] =E2=94=82 ) =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 The alert reader will note that there are no locations or attributes and that the `expression' record layer is omitted here. You can of course configure the printer to display more information if you need to. We've been using these new printers internally to debug migration code and they have been a huge help so we hope they will make working with ppxlib easier for you too. In addition to this new module, we also added a command line utility called `ppxlib-pp-ast' to pretty print ASTs from source files, source code fragments or even marshalled AST files. It is very similar to the old `ppx_tools''s `dumpast'. Note that it will print ppxlib's internal AST after it's been migrated from the installed compiler's version. This is something that we could not simply achieve with OCaml's own `-dparsetree'. This should be a useful tool for debugging ppx related bugs or learning about the AST and we hope ppx authors and users will like it. =E2=97=8A Other changes As mentioned above, we also added some missing `Pprintast~=C2=B9 entries such as ~binding', `longident' and `payload'. It is now possible to use `[@@deriving ...]' on class type declarations and therefore to write derivers for class types. =C2=B9: /To the confused readers:/ `Pprintast' /is entirely different fro= m/ `Pp_ast' /mentioned above as it prints the source code corresponding to a given AST./ Plans for the next release =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=97=8A Internal AST bump to 5.2 Our next release will bump our internal AST to 5.2. It is a pretty big change because 5.2 changed how functions were represented in the AST and this impacts *A LOT* of ppx-es. @patricoferris has been working very hard on this over the past few months to minimize the amount of breakage and to send patches upstream where that was not possible to get the rest of the ecosystem ready for the bump. We wanted to first release the 5.3 compatibility but now that's out of the way we're able to focus on the bump again. @patricoferris will create a dedicated thread shortly to explain a bit what's been going on and what to expect from this release. =E2=97=8A Drop support for OCaml < 4.08 It is time for us to drop support for very old compilers. Keeping support for OCaml 4.07 and before requires maintenances of quite heavy compatibility layers and prevents us from using some language features in ppxlib's source code while providing little to no benefits since the vast majority of users already upgraded to much more recent compilers. If you're still relying on those older compilers and the newest ppxlib, please reach out, either here or via a ppxlib issue. Special thanks =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 We wanted to thank our external contributors for this release: @hhugo, @nojb and @dra27 for their help on the 5.3 compat and @mattiasdrp for bringing the `Pprintast' module up to speed. Special thanks as well to @pedrobslisboa who started integrating their excellent [ppx-by-example] into ppxlib's documentation. Finally, I'd also like to thank the OCaml Software Foundation who's been funding all my work on ppxlib and made this release possible! Happy preprocessing to you all! [ppx-by-example] Release of Carton 1.0.0 and Cachet =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=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'm delighted to announce the release of [Carton 1.0.0] and [Cachet] (which will be released soon into `opam-repository'). Carton is a reimplementation of the Git PACK format. A PACK file is what you can find in your `.git/objects/pack' in your favourite Git repository. It contains mainly all your Git objects. This format provides a good compression ratio and the ability to extract objects almost directly. It can be seen as a read-only key-value database =E2=80= =94 in effect, modifying Git objects is impossible. This project is built around the OCaml implementation of Git that we have. But the PACK format is also interesting in its own right and outside the Git concepts. The PACK format offers double compression. A zlib compression (proposed by [decompress]) as well as a compression between objects in the form of a binary patch (proposed by [duff]). So, if the "words" appear quite frequently (like the words used in a programming language =E2=80=94 if, else, then, etc.), the second level of compression becomes very interesting where an object (such as a file) is simply a succession of patches with other objects. [Carton 1.0.0] [Cachet] [decompress] [duff] Cachet, a library for `mmap' syscall =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 Carton and the PACK format very often use syscall `mmap'. The point is to be able to take advantage of the kernel cache system to read a PACK file. The kernel can read a file in advance when reading a page via `mmap'. Basically, the kernel anticipates that you might want to get the next page after the one you requested. However, in the case of Carton, it is sometimes necessary to =E2=80=98go back=E2=80=99, particularly for patched objects whose source is often upstream. Cachet is an intermediate layer for `mmap' that caches previously obtained pages. In this way, we take advantage of both the kernel for subsequent pages and our library for previous pages. Let's take a concrete example. Carton can analyse a PACK file as `git verify-pack' does. Let's make a comparison with and without Cachet. =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 +--------------+-------------+----------------+----------------= -+ =E2=94=82 | | with cachet | without cachet | git verify-pack= | =E2=94=82 +--------------+-------------+----------------+----------------= -+ =E2=94=82 | time | 17.8s | 41.8s | 9.3s= | =E2=94=82 +--------------+-------------+----------------+----------------= -+ =E2=94=82 | cache misses | 936M | 1933M | 246M= | =E2=94=82 +--------------+-------------+----------------+----------------= -+ =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 As you can see, using Cachet improves Carton's execution time. We're still not as competitive as git-verify-pack, but we're getting close! Cachet offers to cache previously loaded pages. Its cache system is very basic and is just a small array whose size is a power of two. Next, we simply reuse the OCaml hash function =E2=80=94 in this resp= ect, it may be worth testing another hash function. =E2=97=8A Cachet & schedulers Like most of our projects, Cachet is independent of schedulers. There is therefore a variant with [Lwt] and a variant with [Miou]. However, we need to clarify a behaviour related to the use of Cachet. Reading a file, whether with `read(3)' or `mmap(3P)', does not block, but it can take some time. As we have already experienced and explained [here], it may be necessary to explain to the scheduler whether it is appropriate to do something else after such a syscall. In the case of Lwt, it might be a good idea to insert `Lwt.pause' just after our syscall so that Lwt gives another service the opportunity to run despite the time taken trying to read from a file. However, particularly for Lwt, this means closing Cachet in the hell of the monad (in other words, there is no way to escape it) because of this possible `Lwt.pause' (which returns `unit Lwt.t'). The composition of Cachet with Lwt is therefore quite different from what we've been able to experiment with. One of [our other articles] suggests not using functors (too much), and although we can in fact abstract `Lwt.t' from `unit Lwt.t' (and even reduce it such that `type 'a t =3D 'a') with the [HKP] trick, we opted for composition by hand. The problem relates to Lwt (and Async) and doesn't apply to Miou when it's possible to raise effects. However, from such a composition, a choice has been made to give Lwt the opportunity to do something else after `mmap'. We could, in other types of applications, make another choice on this precise question. [Lwt] [Miou] [here] [our other articles] [HKP] Carton =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C Carton is a library that was originally developed for ocaml-git. It was internal to the project but we considered that the PACK format's field of application could be wider than that of Git. We decided to extract the project from `ocaml-git' and make it a library in its own right. Carton's objective remains fairly rudimentary. It consists of: =E2=80=A2 extract objects from a PACK file (whether or not these objects = are Git objects) =E2=80=A2 generate an `*.idx' file from a PACK file in order to have quick access to the objects =E2=80=A2 verifying a PACK file such as `git verify-pack' does =E2=80=A2 and finally generate a PACK file from a list of objects Carton is a library and a tool that you can now use on your Git repositories. Here are a few examples of how to use `carton'. We'll start by cloning a repository to test Carton and go to the folder containing the PACK file. =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 $ opam install carton.1.0.0 =E2=94=82 $ git clone https://github.com/ocaml/ocaml =E2=94=82 $ cd ocaml/.git/objects/pack/ =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Carton can check a PACK file. Verifying means extracting all the objects in the file from memory and calculating their hash. This command is similar to `git verify-pack'. =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 $ carton verify pack-*.pack =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Carton can extract a specific object (commit, tree or blob) from a PACK file using its associated `*.idx' file and the object identifier (the hash of the commit, for example). =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 $ carton get pack-*.idx 89055b054eeec0c6c6b6118d6490b6792da7fef2 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Instead of extracting objects from a PACK file into memory, you can also extract them as files using `explode'. =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 $ mkdir loose =E2=94=82 $ carton explode 'loose/%s/%s' pack-*.pack > entries.pack =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Finally, Carton can create a new PACK file from a list of objects stored in files with make. It can also generate the `*.idx' file associated with the new PACK file. As we've just re-packaged the objects in the repository, we should find the same objects. =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 $ carton make -n $(cat entries.pack | wc -l) -e entries.pack ne= w.pack =E2=94=82 $ carton index new.pack =E2=94=82 $ carton get new.idx 89055b054eeec0c6c6b6118d6490b6792da7fef2 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Please note that the above actions, applied to `ocaml/ocaml', may take some time due to the history of this project. In the example above, we can see the extraction of a Git object, the extraction of all the objects in a PACK file and the creation of a new PACK file based on all the extracted objects. As you can see, creating a PACK file can take a long time. However, the advantage of the PACK file lies particularly in obtaining the objects and in the rate of compression of the PACK file: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 +--------+-------------+----------+-------+--------------+ =E2=94=82 | | pack-*.pack | new.pack | loose | loose.tar.gz | =E2=94=82 +--------+-------------+----------+-------+--------------+ =E2=94=82 | size | 355M | 648M | 8.3G | 1.8G | =E2=94=82 +--------+-------------+----------+-------+--------------+ =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 The PACK file is primarily designed to provide access to objects according to their identifiers. This access must be as fast as possible, even if the object is first compressed with decompress and can be compressed in the form of a patch with duff. Here are a few metrics to give you an idea. =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 +--------------+-------------+----------+---------+ =E2=94=82 | | pack-*.pack | new.pack | loose | =E2=94=82 +--------------+-------------+----------+---------+ =E2=94=82 | git cat-file | ~ 0.01s | N/A | N/A | =E2=94=82 +--------------+-------------+----------+---------+ =E2=94=82 | carton get | ~ 0.20s | ~ 0.30s | | =E2=94=82 +--------------+-------------+----------+---------+ =E2=94=82 | cat | N/A | N/A | 0.0006s | =E2=94=82 +--------------+-------------+----------+---------+ =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 What's important to note is the ability to have random access to objects simply by having the associated `*.idx' file, the production of which is quite efficient. This is not or hardly the case for compression formats such as GZip. And that's the whole point of PACK files, with an indexing method for almost immediate access to objects according to their identifiers and offering a very good compression ratio. *NOTE*: Carton does not compress the repository as well as Git. The main reason is that Git has some heuristics relating to Git objects that Carton does not implement - because Carton wishes to be independent of Git concepts. These heuristics apply in particular to the order in which we want to pack objects. In addition, Git prepares the ground so that the antecedents of a blob object (which is a file in your repository), for example, are the old versions of that same blob (and therefore the old versions of your file). In this context, the patch algorithm implemented by [duff] applies very well and gives very good results. For more details on these heuristics, you can read [this discussion] that serves as documentation. [duff] [this discussion] =E2=97=8A Carton & parallelism As always, our libraries are independent of schedulers. There is a version of Carton with Lwt and a version with Miou. Some of the tasks Carton performs, such as indexing, are highly parallelizable. In this case, the new derivation of Carton with Miou exists to take advantage of the latter's domain pool. It was also quite easy to parallelize the work on `carton index' and `carton verify'. Here are some other metrics which, thanks to OCaml 5 and Miou, bring us closer to Git performance: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 $ hyperfine \ =E2=94=82 -n git \ =E2=94=82 "git verify-pack pack-03a3a824757ff4c225874557c36d44eefe3d7= 918.idx" \ =E2=94=82 -n carton \ =E2=94=82 "carton verify pack-03a3a824757ff4c225874557c36d44eefe3d791= 8.pack -q --threads 4" =E2=94=82 Benchmark 1: git =E2=94=82 Time (mean =C2=B1 =CF=83): 329.2 ms =C2=B1 0.9 ms [U= ser: 384.2 ms, System: 27.8 ms] =E2=94=82 Range (min =E2=80=A6 max): 327.7 ms =E2=80=A6 330.9 ms 1= 0 runs =E2=94=82=20=20 =E2=94=82 Benchmark 2: carton =E2=94=82 Time (mean =C2=B1 =CF=83): 712.1 ms =C2=B1 10.9 ms [U= ser: 1111.8 ms, System: 1112.6 ms] =E2=94=82 Range (min =E2=80=A6 max): 695.4 ms =E2=80=A6 726.8 ms 1= 0 runs =E2=94=82=20=20 =E2=94=82 Summary =E2=94=82 git ran =E2=94=82 2.16 =C2=B1 0.03 times faster than carton =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 *NOTE*: it may come as a surprise that Carton is 2 times slower than Git for analysing a PACK file, but it should be noted that almost the entire Carton implementation is in OCaml! At this stage, the idea is more to give you an idea, but we literally find ourselves comparing a Bugatti with a [Citro=C3=ABn 2CV]. [Citro=C3=ABn 2CV] =E2=97=8A Carton & Emails Finally, this in-depth rewrite of Carton allows us to take advantage of the PACK format for storing our emails. In fact, we are experimenting with and developing an email solution within our cooperative, and email archiving is one of our objectives. Based on our experience of implementing Git, we thought that the PACK format could be a very interesting format for archiving emails. It combines two features, rapid access to emails and compression by patches, which are very interesting when it comes to handling emails. Finally, it also corresponds more or less to the way we use email: =E2=80=A2 we don't want to delete them (more often than not, we want to k= eep them _ad vitam aeternam_) =E2=80=A2 and we don't modify them It therefore corresponds to a sort of read-only database. For more details on this aspect of Carton and the results of our experiments, I suggest you read our [recent article on our cooperative's blog]. [recent article on our cooperative's blog] Opam repository archival, phase 2 - OCaml 4.08 is the lower bound =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=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: Hannes Mehnert 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 It is my pleasure to announce below the list of opam packages that will move to the opam-repository-archive on February 1st 2025. In total there are 5855 opam files scheduled for being moved within 1218 unique packages. This decreases the size of the opam-repository by roughly 20%. /Editor note: please follow the post link for the other articles with whole list./ This list contains all packages that are not compatible with OCaml >=3D 4.08, and packages that after archiving those are not installable due to missing dependencies. The "not installable" list has been generated by [archive-opam], and this may of course contain bugs. A smaller list contains a re-run of phase 1 (packages that are available: false) - where the availability was added between Dec 15th and now. If you find a package in the list and you=E2=80=99d like to retain it in = the opam-repository, there are some options: =E2=80=A2 (a) you can install it on your system (`opam install'): this me= ans there=E2=80=99s a bug in the archive-opam utility, please provide the package name and version in the [opam-repository-archive Phase 2 PR], together with your opam version, OCaml version, and operating system; =E2=80=A2 (b) it is not installable: please figure out the reasoning (the =E2=80=9CReasoning=E2=80=9D may help you to find the root issue), and t= ry to fix it yourself - if you=E2=80=99re unable to fix the root cause, please also comment in the [opam-repository-archive Phase 2 PR] with the package name and version. If you=E2=80=99ve any questions, please don=E2=80=99t hesitate to ask her= e or on GitHub or via another communication channel. You can help further on the archiving process: =E2=80=A2 as mentioned in the last announcement please add the `x-maintenance-intent' to your packages (a good choice for a lot of packages is `x-maintenance-intent: [("latest")]' if you=E2=80=99re maintaining the latest version only) - this will be considered in Phase 3 (March 1st 2025); =E2=80=A2 if you are the author or maintainer of a package that is no lon= ger useful or maintained, you can as well mark your opam files in the opam-repository with `x-maintenance-intent: [("none")]' (this will be taken into account in Phase 3 - March 1st 2025); =E2=80=A2 if you flagged your preliminary releases with `flags: avoid-version', and they can now be removed (e.g. since a stable version has been released), please open a pull request to replace the `avoid-version' with `deprecated'. Please note that the next Phase will be announced on February 15th with all packages where the `x-maintenance-intent' does not match, and which do not have any reverse dependencies - archiving is scheduled for March 1st. To keep track of the announcements, please look at the [opam-repository tag]. A big thanks to the OCaml Software Foundation for funding the opam-repository archival project. [archive-opam] [opam-repository-archive Phase 2 PR] [opam-repository tag] Ocaml-posix 2.1.0 released! =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=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: Romain Beauxis 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 all! Version `2.1.0' of `ocaml-posix' has been released! =E2=80=A2 Repo: =E2=80=A2 API doc: [ocaml-posix] While it was long overdue, this version only include minor changes, along with the addition of `posix-math2'. These packages are intended to provide a consistent, extensive set of bindings for the various POSIX APIs to be used with [ocaml-ctypes] when building bindings to C libraries that require the use of these APIs. While working on OCaml projects, it is common to have to interface with APIs derived from the POSIX specifications, `getaddrinfo', `uname' etc. The core OCaml library provides their own version of these APIs but: =E2=80=A2 They only cover parts of it =E2=80=A2 They wrap some native types such as `socketaddr' into custom, o= paque OCaml types, making it impossible to re-use, for instance when using a C library API requiring a POSIX `sockaddr'. Thus, having a large, consistent set of bindings for these APIs that reflect the actual C types, structures and etc greatly improves the usability of the language and ecosystem as a whole by making it possible to interface it with a large set of C libraries in a reusable way. The project has been mostly stable for a couple of years (and so have the POSIX standards), but could use some more hands if there is more need in the community to extend the set of POSIX APIs supported by the language. [ocaml-posix] [ocaml-ctypes] Release of ocaml-eglot 1.0.0 =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=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: Xavier Van de Woestyne 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 Hi everyone! We (at [Tarides]) are _particularly pleased_ to announce the first release of [OCaml-eglot], An overlay on [Eglot] (the _built-in_ [LSP] client for Emacs) for editing OCaml! =E2=80=A2 [Github repository] =E2=80=A2 [Package on MELPA] =E2=80=A2 [Features list] =E2=80=A2 [Installation procedure] =E2=80=A2 [Comparison table with Merlin] [Tarides] [OCaml-eglot] [Eglot] [LSP] [Github repository] [Package on MELPA] [Features list] [Installation procedure] [Comparison table with Merlin] More precisely =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 Typically, developers who use Emacs (`43.7%' in 2022, [according to the OCaml User Survey]) use a major mode (such as the venerable [caml-mode], or [tuareg]) and [Merlin] to provide IDE services. In 2016, Microsoft has released LSP, a generic protocol for interacting with editors which, at first, was only used by Visual Studio Code, but, since 2020, has really become the norm. De-facto, following the LSP standard gives very good _default_ (completion, jump to definition, =E2=80=A6). OCaml has excellent LSP ([ocaml-lsp-server]) supp= ort, which is used in particular by the [OCaml platform for Visual Studio Code]. With the aim of reducing maintenance for all possible editors, going LSP seems to be a good direction. A pertinent choice, especially since the major historical editors (such as Vim and Emacs) offer, in their recent versions, LSP clients _out of the box_. However, in the same way that the OCaml client for VSCode integrates *OCaml-specific* features, it was necessary to support these features on the Emacs side (and in the future, Vim) to compete with Merlin, which is the goal of `ocaml-eglot', to *provide a tailored development experience for OCaml code editing*! [according to the OCaml User Survey] [caml-mode] [tuareg] [Merlin] [ocaml-lsp-server] [OCaml platform for Visual Studio Code] User feedback and future development =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 We've just released the first version of OCaml-eglot, and, much like the various editor-related projects (Merlin, Vscode-ocaml-platform, Merlin for Emacs, Merlin for Vim), *we're more than open to community collaboration, user feedback*, in order to provide the best possible user experience! _Happy Hacking_! Semgrep is hiring to help scale their static analysis engine =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=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: Emma Jin 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 Semgrep is an application security company focused on detecting and remediating vulnerabilities. The static analysis engine is primarily written in OCaml. We're looking for a software engineer to help us support scanning larger repositories and add many more users. The ideal candidate has owned a critical tool, worked on an OCaml project, and is interested in static analysis. If this sounds interesting to you, see our job posting at ! Let me know if you have any questions! 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: Etienne Marais 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 Dune enthusiasts :camel:, We will hold the regular Dune Dev Meeting on *Wednesday, January, 22nd at 16:00* CET. As usual, the session will be one hour long. Whether you are a maintainer, a regular contributor, a new joiner or just curious, you are welcome to join: these discussions are opened! The goal of these meetings is to provide a place to discuss the ongoing work together and synchronize with the Dune developers! :calendar: Agenda =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 The agenda is available on the[ meeting dedicated page]. Feel free to ask if you want to add more items in it. [ meeting dedicated page] :computer: Links =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=80=A2 Meeting link: [zoom] =E2=80=A2 Calendar event: [google calendar] =E2=80=A2 Wiki with information and previous notes: [GitHub Wiki] [zoom] [google calendar] [GitHub Wiki] Tarides: 2024 in Review =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=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: Thomas Gazagnaire 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 At [Tarides], we believe in making OCaml a mainstream programming language by improving its tooling and integration with other successful ecosystems. In 2024, we focused our efforts on initiatives to advance this vision by addressing key technical challenges and engaging with the community to build a stronger foundation for OCaml=E2= =80=99s growth. This report details our work, the rationale behind our choices, and the impact achieved. We are very interested in getting your feedback: [please get in touch] (or respond to this thread!) if you believe we are going in the right direction. /__TL;DR__ =E2=80=93 In 2024, Tarides focused on removing adoption fricti= on with better documentation and tools; and on improving adoption via the integration with three key thriving ecosystems: multicore programming, web development, and Windows support. Updates to [ocaml.org] improved onboarding and documentation, while the [Dune Developer Preview] simplified workflows with integrated package management. Merlin added support for [project-wide reference support] and [odoc 3], which is about to be released. OCaml 5.3 marked the first stable multicore release, and `js_of_ocaml' achieved up to 8x performance boosts in real-world commercial applications thanks to added support for WebAssembly. On Windows, opam 2.2 brought full compatibility and CI testing to all Tier 1 platforms on `opam-repository', slowly moving community packages towards reliable and better support for Windows. Tarides=E2=80=99 community support included organising the first= [FUN OCaml conference], many local meetups, and two rounds of Outreachy internships./ [Tarides] [please get in touch] [ocaml.org] [Dune Developer Preview] [project-wide reference support] [odoc 3] [FUN OCaml conference] Better Tools: Toward a 1-Click Installation of OCaml =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=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 Our primary effort in 2024 was to continue delivering on the [OCaml Platform roadmap] published last year. We focused on making it easier to get started with OCaml by removing friction in the installation and onboarding process. Our priorities were guided by the latest [OCSF User Survey], direct user interviews, and [feedback] gathered from the OCaml community. Updates from Tarides and other OCaml Platform maintainers were regularly shared in the [OCaml Platform Newsletter]. [OCaml Platform roadmap] [OCSF User Survey] [feedback] [OCaml Platform Newsletter] =E2=97=8A OCaml.org OCaml.org is the main entry point for new users of OCaml. Tarides engineers are key members of the OCaml.org team. Using [privacy-preserving analytics], the team tracked visitor behaviour to identify key areas for improvement. This led to a redesign of the [installation page], simplifying the setup process, and a revamp of the [guided tour of OCaml] to better introduce the language. Both pages saw significant traffic increases compared to 2023, with the installation page recording 69k visits, the tour reaching 65k visits and a very encouraging total number of visits increasing by +33% between Q3 and Q4 2024 Efforts to improve user experience included a satisfaction survey where 75% of respondents rated their experience positively, compared to 17% for the previous version of the site. User testing sessions with 21 participants provided further actionable insights, and these findings informed updates to the platform. The redesign of OCaml.org community sections was completed using this feedback. It introduced several new features: a new [Community landing page], an [academic institutions page] with course listings, and an [industrial users showcase]. The team also implemented an automated [event announcement] system to inform the community of ongoing activities. Progress and updates were regularly shared through the [OCaml.org newsletters], keeping the community informed about developments. Looking ahead, the team will continue refining the platform by addressing feedback, expanding resources, and monitoring impact through analytics to support both new and experienced OCaml users. Lastly, the infrastructure they build is starting to be used by other communities: [Rocq] just announced their brand new website, built using the same codebase as ocaml.org! [privacy-preserving analytics] [installation page] [guided tour of OCaml] [Community landing page] [academic institutions page] [industrial users showcase] [event announcement] [OCaml.org newsletters] [Rocq] =E2=97=8A Dune as the Default Frontend of the OCaml Platform One of the main goals of the OCaml Platform is to make it easier for users=E2=80=94especially newcomers=E2=80=94to adopt OCaml and build proje= cts with minimal friction. A critical step toward this goal is having a single CLI to serve as the frontend for the entire OCaml development experience (codenamed [Bob] in the past). This year, we made significant progress in that direction with the release of the [Dune Developer Preview]. Setting up an OCaml project currently requires multiple tools: `opam' for package management, `dune' for builds, and additional installations for tools like OCamlFormat or Odoc. While powerful, this fragmented workflow can make onboarding daunting for new users. The Dune Developer Preview consolidates these steps under a single CLI, making OCaml more approachable. With this preview, setting up and building a project is as simple as: 1. `dune pkg lock' to lock the dependencies. 2. `dune build' to fetch the dependencies and compile the project. This effort is also driving broader ecosystem improvements. The current OCaml compiler relies on fixed installation paths, making it difficult to cache and reuse across environments, so it cannot be shared efficiently between projects. To address this, we are working on making the compiler relocatable ([ongoing work]). This change will enable compiler caching, which means faster project startup times and fewer rebuilds in CI. As part of this effort, we also [maintain] patches to core OCaml projects to make them relocatable =E2=80=93 and we worked with upstream to merge (like [for ocamlfind]). Tarides engineers also continued to maintain Dune and other key Platform projects, ensuring stability and progress. This included organising and participating in regular development meetings (for [Dune], [opam], [Merlin], [ppxlib], etc.) to prioritise community needs and align efforts across tools like Dune and opam to avoid overlapping functionality. The Dune Developer Preview is an iterative experiment. Early user feedback has been promising (the Preview=E2=80=99s NPS went from +9 in Q3= 2024 to +27 in Q4 2024), and future updates will refine the experience further. We aim to ensure that experimental features in the Preview are upstreamed into stable releases once thoroughly tested. For instance, the package management feature is already in Dune 3.17. We will announce and document it more widely when we believe it is mature enough for broader adoption. [Bob] [Dune Developer Preview] [ongoing work] [maintain] [for ocamlfind] [Dune] [opam] [Merlin] [ppxlib] =E2=97=8A Editors In 2024, Tarides focused on improving editor integration to lower barriers for new OCaml developers and enhance the experience for existing users. Editors are the primary way developers interact with programming languages, making seamless integration essential for adoption. With more than [73% of developers using Visual Studio Code (VS Code)], VS Code is particularly important to support, especially for new developers and those transitioning to OCaml. As part of this effort, Tarides wrote and maintained the [official VS Code plugin for OCaml,] prioritising feature development for this editor. We also support other popular editors like Emacs and Vim=E2=80=94used by many Tar= ides engineers=E2=80=94on a best-effort basis. Improvements to [OCaml-LSP] and [Merlin], both maintained by Tarides, benefit all supported editors, ensuring a consistent and productive development experience. While several plugins for OCaml exist ([OCaml and Reason IDE]=E2=80=93128k installs, [Hackwaly]=E2=80=9390k installs), our [OCaml VS Code plugin] = =E2=80=93now with over 208k downloads=E2=80=93 is a key entry point for developers ado= pting OCaml in 2024. This year, we added integration with the Dune Developer Preview, allowing users to leverage Dune's package management and tooling directly from the editor. Features such as real-time diagnostics, autocompletion, and the ability to fetch dependencies and build projects without leaving VS Code simplify development and make OCaml more accessible for newcomers. The standout update in 2024 was the addition of [project-wide reference support], a long-requested feature from the OCaml community and a top priority for commercial developers. This feature allows users to locate all occurrences of a term across an entire codebase, making navigation and refactoring significantly easier=E2=80=94especially= in large projects. Delivering this feature required coordinated updates across the ecosystem, including changes to the OCaml compiler, Merlin, OCaml LSP, Dune, and related tools. The impact is clear: faster navigation, reduced cognitive overhead, and more efficient workflows when working with complex projects. Additional improvements included support for new Language Server Protocol features, such as `signature_help' and `inlay_hint', which enhance code readability and provide more contextual information. These updates enabled the introduction of new commands, such as the "Destruct" command. This [little-known but powerful feature] automatically expands a variable into a pattern-matching expression corresponding to its inferred type, streamlining tasks that would otherwise be tedious. [73% of developers using Visual Studio Code (VS Code)] [official VS Code plugin for OCaml,] [OCaml-LSP] [Merlin] [OCaml and Reason IDE] [Hackwaly] [OCaml VS Code plugin] [project-wide reference support] [little-known but powerful feature] =E2=97=8A Documentation Documentation was identified as the number one pain point in the latest [OCSF survey]. It is a critical step in the OCaml developer journey, particularly after setting up the language and editor. Tarides prioritised improving `odoc' to make it easier for developers to find information, learn the language, and navigate the ecosystem effectively. High-quality documentation and tools to help developers get "unstuck" are essential to reducing friction and ensuring a smooth adoption experience. Tarides is the primary contributor and maintainer of [`odoc'], OCaml=E2= =80=99s main documentation tool. In preparation for the [odoc 3 release], our team introduced two significant updates. First, the [`odoc' Search Engine] was integrated, allowing developers to search directly within OCaml documentation via the [Learn page]. Second, the [`odoc' Cheatsheet] provides a concise reference for creating and consuming OCaml documentation. We would like to believe that these updates, deployed on ocaml.org, were the main cause of a **45% increase in package documentation usage** on [https://ocaml.org/pkg/] in Q4 2024! Another area where developers often get stuck is debugging programs that don=E2=80=99t work as expected. Alongside reading documentation, live debuggers are crucial for understanding program issues. Tarides worked to improve native debugging for OCaml, focusing on macOS, where LLDB is the only supported debugger. Key progress included a [name mangling fix] to improve symbol resolution, restoring ARM64 backtraces, and introducing Python shims for code sharing between LLDB and GDB. OCaml=E2=80=99s error messages remain a common pain point, particularly f= or syntax errors. Unlike [Rust=E2=80=99s error index], OCaml does not (yet!)= have a centralised repository of error explanations. Instead, we are focused on making error messages more self-explanatory. This requires developing new tools, such as [`lrgrep'], a domain-specific language for analysing grammars built with Menhir. `lrgrep' enables concise definitions of error cases, making it possible to identify and address specific patterns in the parser more effectively. This provides a practical way to improve error messages without requiring changes to the compiler. In December 2024, @let-def successfully defended his PhD (a collaboration between Inria and Tarides) on this topic, so expect upstreaming work to start soon. [OCSF survey] [`odoc'] [odoc 3 release] [`odoc' Search Engine] [Learn page] [`odoc' Cheatsheet] [https://ocaml.org/pkg/] [name mangling fix] [Rust=E2=80=99s error index] [`lrgrep'] =E2=97=8A OCaml Package Ecosystem The last piece of friction we aimed to remove in 2024 was ensuring that users wouldn=E2=80=99t encounter errors when installing a package fr= om the community. This required catching issues early=E2=80=94before package= s are accepted into `opam-repository' and made available to the broader ecosystem. To achieve this, Tarides has built and maintained extensive CI infrastructure, developed tools to empower contributors, and guided package authors to uphold the high quality of the OCaml package ecosystem. In 2024, Tarides=E2=80=99 CI infrastructure supported the OCaml community= at scale, handling approximately **20 million jobs on 68 machines covering 5 hardware architectures**. This infrastructure continuously tested packages to ensure compatibility across a variety of platforms and configurations, including OCaml=E2=80=99s Tier 1 platforms: x86, ARM, RISC-V, s390x, and Power. It played a critical role during major events, such as new OCaml releases, by validating the ecosystem=E2=80=99s readiness and catching regressions before they impacted users. Additionally, this infrastructure supported daily submissions to `opam-repository', enabling contributors to identify and resolve issues early, reducing downstream problems. To improve transparency and accessibility, we introduced a CI pipeline that automates configuration updates, ensuring seamless deployments and allowing external contributors to propose and apply changes independently. In addition to maintaining the infrastructure, Tarides developed and maintained the CI framework running on top of it. A major focus in 2024 was making CI checks available as standalone CLI tools distributed via `opam'. These tools enable package authors to run checks locally, empowering them to catch issues before submitting their packages to `opam-repository'. This approach reduces reliance on central infrastructure and allows developers to work more efficiently. The CLI tools are also compatible with GitHub Actions, allowing contributors to integrate tests into their own workflows. To complement these efforts, we enhanced `opam-repo-ci', which remains an essential safety net for packages entering the repository. Integration tests for linting and reverse dependencies were introduced, enabling more robust regression detection and improving the reliability of the ecosystem. To uphold the high standards of the OCaml ecosystem, every package submission to `opam-repository' is reviewed and validated to ensure it meets quality criteria. This gatekeeping process minimises errors users might encounter when installing community packages, enhancing trust in the ecosystem. In 2024, Tarides continued to be actively [involved] in maintaining the repository, ensuring its smooth operation. We also worked to guide new package authors by updating the [contributing guide] and creating a detailed [wiki] with actionable instructions for adding and maintaining packages. These resources were [announced on Discuss] to reach the community and simplify the process for new contributors, improving the overall quality of submissions. [involved] [contributing guide] [wiki] [announced on Discuss] Playing Better with the Larger Ecosystem =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=E2=95=8C =E2=97=8A Concurrent & Parallel Programming in OCaml _"Shared-memory multiprocessors have never really 'taken off', at least in the general public. For large parallel computations, clusters (distributed-memory systems) are the norm. For desktop use, monoprocessors are plenty fast."_ =E2=80=93 [Xavier Leroy, November 2002] Twenty+ years after this statement, processors are multicore by default, and OCaml has adapted to this reality. Thanks to the combined efforts of the OCaml Labs and Tarides team, the OCaml 5.x series introduced multicore support after [a decade of research and experimentation.] While this was a landmark achievement, the path to making multicore OCaml stable, performant, and user-friendly has required significant collaboration and continued work. In 2024, Tarides remained focused on meeting the needs of the broader community and commercial users. OCaml 5.3 (released last week) was an important milestone in this journey. With companies such as [Routine], [Hyper], and [Asemio] adopting OCaml 5.x, and advanced experimentation ongoing at Jane Street, Tezos, Semgrep, and others, OCaml 5.3 is increasingly seen as the first =E2=80=9Cstable=E2=80=9D release of the multicore series. While= some [performance issues] remain in specific parts of the runtime, we are working closely with the community to address them in OCaml 5.4. Tarides contributed extensively to the [5.2] and [5.3] releases by directly contributing to **nearly two-thirds of the merged pull requests**. Since Multicore OCaml was incorporated upstream in 2023, we have been continuously involved in the compiler and language evolution in collaboration with Inria and the broader OCaml ecosystem. Developing correct concurrent and parallel software is inherently challenging, and this applies as much to the runtime as to applications built on it. In 2024, we focused on advanced testing tools to help identify and address subtle issues in OCaml=E2=80=99s runti= me and libraries. The [property-based test suite] reached maturity this year, uncovering over 40 critical issues, with 28 resolved by Tarides engineers. Trusted to detect subtle bugs, such as [issues with orphaned ephemerons], the suite has become an integral part of OCaml=E2= =80=99s development workflow. Importantly, it is accessible to contributors without deep expertise in multicore programming, ensuring any changes in the compiler or the runtime do not introduce subtle concurrency bugs. Another critical effort was extending ThreadSanitizer (TSAN) support to most Tier 1 platforms and [applying it extensively to find and fix data races in the runtime]. This work has improved the safety and reliability of OCaml=E2=80=99s multicore features and is now part of the standard testing process, further ensuring the robustness of the runtime. Beyond testing, we also worked to enhance library support for multicore programming. The release of the [Saturn library] introduced lock-free data structures tailored for OCaml 5.x. To validate these structures, we developed [DSCheck], a static analyser for verifying lock-free algorithms. These tools, along with Saturn itself, provide developers with reliable building blocks for scalable multicore applications. Another promising development in 2024 was the introduction of the [Picos] framework. Picos aims to provide a low-level foundation for concurrency, simplifying interoperability between libraries like Eio, Moonpool, Miou, Riot, Affect, etc. Picos offers a simple, unopinionated, and safe abstraction layer for concurrency. We believe it can potentially standardise concurrency patterns in OCaml, but we are not there yet. Discussions are underway to integrate parts of Picos into higher-level libraries and, eventually, the standard library. We still have a long way to go, and getting feedback from people who actively tried it in production settings would be very helpful! [Xavier Leroy, November 2002] [a decade of research and experimentation.] [Routine] [Hyper] [Asemio] [performance issues] [5.2] [5.3] [property-based test suite] [issues with orphaned ephemerons] [applying it extensively to find and fix data races in the runtime] [Saturn library] [DSCheck] [Picos] =E2=97=8A Web Web development remains one of the most visible and impactful domains for programming languages; [JavaScript, HTML, and CSS are the most popular technologies] in 2024. For OCaml to grow, it must integrate well with this ecosystem. Fortunately, the OCaml community has already built a solid foundation for web development! On the frontend side, in 2024, Tarides focused on strengthening key tools like [`js_of_ocaml'] by expanding its support for WebAssembly (Wasm). `js_of_ocaml' (JSOO) has long been the backbone of OCaml=E2=80=99= s web ecosystem, enabling developers to compile OCaml bytecode into JavaScript. This year, we [merged Wasm support back into JSOO], unifying the toolchain and simplifying adoption for developers. The performance gain of Wasm has been very impressive so far: CPU-intensive applications in commercial settings have seen **2x to 8x speedups** using Wasm compared to traditional JSOO. We also worked on better support for effect handlers in `js_of_ocaml' to ensure applications built with OCaml 5 can run as fast in the browser as they used to with OCaml 4. On the backend side, Tarides maintained and contributed to Dream, a lightweight and flexible web framework. Dream powers projects like [our own website] and the [MirageOS website], where we maintain a fork to make Dream and MirageOS work well together. Additionally, in 2024, we enhanced `cohttp', adding [proxy support] to address modern HTTP requirements. While Tarides focused on JSOO, `wasm_of_ocaml', Dream, and Cohttp, the broader community made significant strides elsewhere. Tools like Melange offer an alternative for compiling OCaml to JavaScript, and frameworks like Ocsigen, which integrates backend and frontend programming, continue to push the boundaries of what=E2=80=99s possible w= ith OCaml on the web. Notably, Tarides will build on this momentum in 2025 through a [grant] to improve direct-style programming for Ocsigen. [JavaScript, HTML, and CSS are the most popular technologies] [`js_of_ocaml'] [merged Wasm support back into JSOO] [our own website] [MirageOS website] [proxy support] [grant] =E2=97=8A Windows Windows is the most widely used operating system, making first-class support for it critical to OCaml=E2=80=99s growth. In 2024, **31% of visi= tors to [ocaml.org]** accessed the site from Windows, yet the platform=E2=80= =99s support historically lagged behind Linux and macOS. This gap created barriers for both newcomers and commercial users. We saw these challenges firsthand, with Outreachy interns struggling to get started due to tooling issues, and commercial users reporting difficulties with workflow reliability and compilation speed. To address these pain points, Tarides, in collaboration with the OCaml community, launched the [Windows Working Group]. A key milestone that our team contributed to was the release this year of **opam 2.2**, three years after its predecessor. This release made the upstream `opam-repository' fully compatible with Windows for the first time, removing the need for a separate repository and providing Windows developers access to the same ecosystem as Linux and macOS users. The impact has been clear: feedback on the updated installation workflow has been overwhelmingly positive, with developers reporting that it "just works." The [install page] for Windows is now significantly shorter and simpler! In the OCaml 5.3 release, Tarides restored the MSVC Windows port, ensuring native compatibility and improving performance for Windows users. To further support the ecosystem, Tarides added Windows machines to the opam infrastructure, enabling automated testing for Windows compatibility on every new package submitted to opam. This has already started to improve package support, with ongoing fixes from Tarides and the community. The results are publicly visible at [windows.check.ci.dev], which we run on our infrastructure, providing transparency and a way to track progress on the status of our ecosystem. While package support is not yet on par with other platforms, we believe that the foundations laid in 2024=E2=80=94simplified installation, improved tooling, and continuous package testing=E2=80=94represent a significant step forward. [ocaml.org] [Windows Working Group] [install page] [windows.check.ci.dev] Community Engagement and Outreach =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 In 2024, Tarides contributed to building a stronger OCaml community through events, internships, and support for foundational projects. The creation of [FUN OCaml 2024] in Berlin was the first dedicated OCaml-only event for a long time (similar to how the OCaml Workshop was separated from ICFP in the past). Over 75 participants joined for two days of talks, workshops, and hacking, and the event has already reached [5k+ views on YouTube]. Tarides also co-chaired the OCaml Workshop at [ICFP 2024] in Milan, bringing together contributors from academia, industry, and open-source communities. These events brought together two different kinds of OCaml developers (with some overlap), bringing an interesting energy to our community. To expand local community involvement, Tarides organised OCaml hacking meetups in [Manila] and [Chennai]. To make it easier for others to host similar events, we curated a list of interesting hacking issues from past [Cambridge sessions], now available on [GitHub]. As part of the Outreachy program, Tarides supported two rounds of internships in 2024, with results published on [Discuss] and [watch.ocaml.org]. These internships not only provided great contributions to our ecosystem but also brought fresh insights into the challenges faced by new users. For example, interns identified key areas where documentation and tooling could be improved, directly informing future updates. Tarides also maintained its commitment to funding critical open-source projects and maintainers. We continued funding [Robur] for their maintenance work on MirageOS (most of those libraries are used by many =E2=80=93including us=E2=80=93 even in non-MirageOS context) and [Daniel = B=C3=BCnzli], whose libraries like `cmdliner' are essential for some of our development. Finally, Tarides extended sponsorships to non-OCaml-specific events, including [JFLA], [BobConf], [FSTTCS], and [Terminal Feud] (which garnered over 100k views). These events expanded OCaml=E2=80=99s visibili= ty to new audiences and contexts, introducing the language to a broader technical community that =E2=80=93we hope=E2=80=93 will discover OCaml an= d enjoy using it as much as we do. [FUN OCaml 2024] [5k+ views on YouTube] [ICFP 2024] [Manila] [Chennai] [Cambridge sessions] [GitHub] [Discuss] [watch.ocaml.org] [Robur] [Daniel B=C3=BCnzli] [JFLA] [BobConf] [FSTTCS] [Terminal Feud] What=E2=80=99s Next? =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 As we begin 2025, Tarides remains committed to making OCaml a mainstream language. Our focus this year is to position OCaml as a robust choice for mission-critical applications by enhancing developer experience, ecosystem integration, and readiness for high-assurance use cases. We aim to build on the Dune Developer Preview to further improve usability across all platforms, with a particular emphasis on Windows, to make OCaml more accessible to a broader range of developers. Simultaneously, we will ensure OCaml is ready for critical applications in industries where reliability, performance, and security are essential. Projects like [SpaceOS] showcase the potential of memory- and type-safe languages for safety-critical systems. Built on MirageOS and OCaml=E2=80=99s unique properties, SpaceOS is part of the EU-funded [Orchide] project and aims to set a new standard for edge computing in space. Additionally, SpaceOS is being launched in the US through our spin-off [Parsimoni]. However, these needs are not limited to Space: both the [EU Cyber Resilience Act] and the [US cybersecurity initiatives] highlight the growing demand for type-safe, high-assurance software to address compliance and security challenges in sensitive domains. Tarides believes that OCaml has a decisive role to play here in 2025! I=E2=80=99d like to personally thank our sponsors and customers, especial= ly Jane Street, for their unwavering support over the years, and to [Dennis Dang], our single recurring GitHub sponsor. Finally, to every member of Tarides who worked so hard in 2024 to make all of this happen: thank you. I=E2=80=99m truly lucky to be sailing with you on this journey! /We are looking for [sponsors on GitHub], are happy to [collaborate on innovative projects] involving OCaml or MirageOS and offer [commercial services] for open-source projects =E2=80=93 including long-term support, development of new tools, or assistance with porting projects to OCaml 5 or Windows./ [SpaceOS] [Orchide] [Parsimoni] [EU Cyber Resilience Act] [US cybersecurity initiatives] [Dennis Dang] [sponsors on GitHub] [collaborate on innovative projects] [commercial services] 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 [Using `clang-cl' With OCaml 5] =E2=80=A2 [Florian=E2=80=99s compiler weekly, 13 January 2025] =E2=80=A2 [OCaml 5.3: Features and Fixes!] =E2=80=A2 [Git, Carton and emails] [the ocaml.org blog] [Using `clang-cl' With OCaml 5] [Florian=E2=80=99s compiler weekly, 13 January 2025] [OCaml 5.3: Features and Fixes!] [Git, Carton and emails] 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 January 14 to 21, 202= 5.

OCaml Software Foundation: January 2025 update

Archive: https://discuss.ocaml.org/t/ocaml-software-foun= dation-january-2025-update/15951/1

gasche announced

Happy new year!

This is an update on recent works of the O= Caml Software Foundation, covering our 2024 actions – the previo= us update was in January 2024.

The OCaml Software Foundation is a non-profit foundation (earlier threa= d) that receives funding from our industrial sponsors each year, and tries its best to spend it to s= upport and strengthen the OCaml ecosystem and community.

The funding volume we receive each year is around 200K=E2=82=AC. (For compa= rison: this is the yearly cost of one experienced full-time software engine= er in many parts of the world.) We do not fund people full-time for long pe= riods. Most actions receive from 3K=E2=82=AC to 20K=E2=82=AC. The work to = prepare and execute actions is mostly done by the (unpaid) Executive Committee. It is currently formed b= y Nicol=C3=A1s Ojeda B=C3=A4r, Damien Doligez, Xavier Leroy, Kim Nguy=E1=BB= =85n, Virgile Prevosto and myself, with administrative personnel provided b= y INRIA and general assistance by Alan = Schmitt.

Our current sponsors (thanks!) are ahrefs, Jane Street, Tezos, Bloomberg, <= a href=3D"https://lexifi.com/">Lexifi, SimCorp, MERCE = and Tarides. (If your company would li= ke to join as a sponsor, please get in touch. Unfortunately, we still cannot efficiently proce= ss small donations, so we are not calling for individual donations.)

Feel free to use this thread for questions/suggestions :-)

Recent actions

  • Education and outreach

    We funded a new edition of the Spanish summer school on functional programming in OCaml, org= anized in Saragossa by Ricardo Rodriguez and Roberto Blanco.

    We continued funding the OCaml meetups in Paris and Toulouse, France. In 20= 24, a new meetup started in Chennai, India (first discuss thread), which we are del= ighted to support as well.

    We are sponsoring the JFLA = 2025, a functional programming conference in France, and an OCaml Bridge Workshop at Functional Conf 2025, a lar= ge Asian conference on functional programming.

  • Research

    The OCaml Software Foundation is typically not involved in funding research= , focusing on actions that have an immediate impact on the language and its= community. Nevertheless, in 2023 we funded one year of post-doctoral work = for Takafumi Saikawa in relation to his maintenance work on the type-checke= r of OCaml. In 2024 we funded one year of research engineer for the Salto project, building a stat= ic analyzer for OCaml, and one year of PhD grant for Alistair O'Brien in Cambridge (complementing other fun= ding sources for a full PhD), continuing his impressive work on constraint-based type inference = for OCaml.

  • Ecosystem
    • Infrastructure

      As in previous years, we fund the work of Kate Deplaix to check that the OC= aml ecosystem is compatible with upcoming compiler releases; in 2024 Kate w= orked on OCaml 5.2 and 5.3.

      We are trying our best to support the work of opam-repository maintainers, = through individual funding grants for the active maintainers. This year, on= the suggestion of the repository maintainers, we are also funding the work= of Robur to migrate unmaintained packa= ges to a separate archive (discuss thread 1, thread 2).

    • Tools

      In 2024 we have funded one month of maintenance of the opam cl= ient by Raja Boujbel and her colleagues.

      We renewed our partial support for the work of Antonio Monteiro on Melange. For more Melange news, see for= example the announcement of Melange 4.

    • Libraries

      We keep supporting the work of Petter Urkedal on the Caqti library, the main database connec= tion library in the OCaml community.

      The Owl library for scientif= ic computing has been restructuring in 2024, with its two maintainers movin= g to permanent jobs demanding their time and therefore less available. The = OCaml Software Foundation is providing a small grant to help the maintainer= s transition to a different contribution model and/or preserve a part of th= eir maintenance activity, as they think is best.

      We have been funding documentation work by John Whitington to collect or cr= eate usage examples of important OCaml libraries, prior to their upstreamin= g in the documentation of each project. See his ocaml-nursery repository.

      We support the contributions of Daniel B=C3=BCnzli to the OCaml ecosystem. = This year, Daniel used this support to fund the development of

      • jsont, a new library for declarativ= e JSON data manipulation
      • bytesrw, a library of composable by= te stream readers and writes, with support for various compression and hash= ing algorithms
      • support for Unicode 16.0 in his Unicode l= ibraries

      Finally, we have been funding Nathan Rebours to take an active part in the = maintenance of the ppxlib project, see his ppxlib maintenance summary.

ppxlib.034.0

Archive: h= ttps://discuss.ocaml.org/t/ann-ppxlib-034-0/15952/1

Nathan Rebours announced

We're happy to announce that we just released ppxlib.0.34.0.

The full patch notes are available on the release page over here.

The main features are OCaml 5.3 compatibility, new AST pretty-printing util= ities and the ppxlib-tools package, support for [@@deriving ...] on class types and the addition of missing Pprintast entry = points.

Changes summary

  • 5.3 compatibility

    ppxlib.0.34.0 is the first official ppxlib release that's compatible with t= he new 5.3 compiler.

    The ppxlib driver now also comes with a -keywords CLI option, = similar to the compiler's that allow you to compile and preprocess with the= 5.3 compiler code that uses effect as an identifier. This is = pretty niche but it's there should you need it.

    Please note that means you can use ppx-es with a 5.3 compiler but not that = ppx-es can consume/produce 5.3 language features. We're currently working o= n a fix allowing you to use the effect syntax in files that require preproc= essing as it's not possible with 0.34.0. The fix should be released in the = next few days as 0.34.1.

  • AST pretty-printing

    We added a new Pp_ast module that allows you to pretty print A= ST fragments.

    The only way ppxlib would print ASTs before were as S-expressions. In pract= ice we found that it was not always helpful and wanted a more readable and = human friendly way of displaying the AST.

    The default output of those printer is a simplified version of the AST to k= eep things clear and avoid cluttering the output with information that is n= ot always useful. For example, if you run Ppxlib.Pp_ast.Default.expre= ssion on the AST for x + 2, you'll get the following: 

    Pexp_apply
  ( Pexp_ident (Lident "+")
  , [ ( Nolabel<=
/span>, Pexp_ide=
nt (Liden=
t "x"))
    ; ( Nolabel<=
/span>, Pexp_con=
stant (Pc=
onst_integer ( "2", None)))
    ]
  )

    The alert reader will note that there are no locations or attributes and th= at the expression record layer is omitted here.

    You can of course configure the printer to display more information if you = need to.

    We've been using these new printers internally to debug migration code and = they have been a huge help so we hope they will make working with ppxlib ea= sier for you too.

    In addition to this new module, we also added a command line utility called= ppxlib-pp-ast to pretty print ASTs from source files, source = code fragments or even marshalled AST files. It is very similar to the old = ppx_tools's dumpast.

    Note that it will print ppxlib's internal AST after it's been migrated from= the installed compiler's version. This is something that we could not simp= ly achieve with OCaml's own -dparsetree.

    This should be a useful tool for debugging ppx related bugs or learning abo= ut the AST and we hope ppx authors and users will like it.

  • Other changes

    As mentioned above, we also added some missing Pprintast~=C2=B9 entri= es such as ~binding, longident and payload.

    It is now possible to use [@@deriving ...] on class type decla= rations and therefore to write derivers for class types.

    =C2=B9: To the confused readers: Pprintast is entire= ly different from Pp_ast mentioned above as it prints t= he source code corresponding to a given AST.

Plans for the next release

  • Internal AST bump to 5.2

    Our next release will bump our internal AST to 5.2. It is a pretty big chan= ge because 5.2 changed how functions were represented in the AST and this i= mpacts A LOT of ppx-es.

    @patricoferris has been working very hard on this over the past few months = to minimize the amount of breakage and to send patches upstream where that = was not possible to get the rest of the ecosystem ready for the bump.

    We wanted to first release the 5.3 compatibility but now that's out of the = way we're able to focus on the bump again.

    @patricoferris will create a dedicated thread shortly to explain a bit what= 's been going on and what to expect from this release.

  • Drop support for OCaml < 4.08

    It is time for us to drop support for very old compilers. Keeping support f= or OCaml 4.07 and before requires maintenances of quite heavy compatibility= layers and prevents us from using some language features in ppxlib's sourc= e code while providing little to no benefits since the vast majority of use= rs already upgraded to much more recent compilers.

    If you're still relying on those older compilers and the newest ppxlib, ple= ase reach out, either here or via a ppxlib issue.

Special thanks

We wanted to thank our external contributors for this release: @hhugo, @noj= b and @dra27 for their help on the 5.3 compat and @mattiasdrp for bringing = the Pprintast module up to speed.

Special thanks as well to @pedrobslisboa who started integrating their exce= llent ppx-by-ex= ample into ppxlib's documentation.

Finally, I'd also like to thank the OCaml Software Foundation who's been fu= nding all my work on ppxlib and made this release possible!

Happy preprocessing to you all!

Release of Carton 1.0.0 and Cachet

Archive: https://discuss.ocaml.org/t/ann-release-of-carton-1-0-= 0-and-cachet/15953/1

Calascibetta Romain announced

I'm delighted to announce the release of Carton 1.0.0 and Cachet (which will be released soon into opam-repositor= y).

Carton is a reimplementation of the Git PACK format. A PACK file is what yo= u can find in your .git/objects/pack in your favourite Git rep= ository. It contains mainly all your Git objects. This format provides a go= od compression ratio and the ability to extract objects almost directly. It= can be seen as a read-only key-value database =E2=80=94 in effect, modifyi= ng Git objects is impossible.

This project is built around the OCaml implementation of Git that we have. = But the PACK format is also interesting in its own right and outside the Gi= t concepts.

The PACK format offers double compression. A zlib compression (proposed by = decompress) as well as= a compression between objects in the form of a binary patch (proposed by <= a href=3D"https://github.com/mirage/duff">duff).

So, if the "words" appear quite frequently (like the words used in a progra= mming language =E2=80=94 if, else, then, etc.), the second level of compres= sion becomes very interesting where an object (such as a file) is simply a = succession of patches with other objects.

Cachet, a library for mmap syscall

Carton and the PACK format very often use syscall mmap. The po= int is to be able to take advantage of the kernel cache system to read a PA= CK file. The kernel can read a file in advance when reading a page via mmap. Basically, the kernel anticipates that you might want to get= the next page after the one you requested.

However, in the case of Carton, it is sometimes necessary to =E2=80=98go ba= ck=E2=80=99, particularly for patched objects whose source is often upstrea= m.

Cachet is an intermediate layer for mmap that caches previousl= y obtained pages. In this way, we take advantage of both the kernel for sub= sequent pages and our library for previous pages.

Let's take a concrete example. Carton can analyse a PACK file as git = verify-pack does. Let's make a comparison with and without Cachet. 

+--------------+-------------+----------------+-----------------+
|              | with cachet | without cachet | git verify-pack |
+--------------+-------------+----------------+-----------------+
|         time |       17.8s |          41.8s |            9.3s |
+--------------+-------------+----------------+-----------------+
| cache misses |        936M |          1933M |            246M |
+--------------+-------------+----------------+-----------------+

As you can see, using Cachet improves Carton's execution time. We're still = not as competitive as git-verify-pack, but we're getting close!

Cachet offers to cache previously loaded pages. Its cache system is very ba= sic and is just a small array whose size is a power of two. Next, we simply= reuse the OCaml hash function =E2=80=94 in this respect, it may be worth t= esting another hash function.

  • Cachet & schedulers

    Like most of our projects, Cachet is independent of schedulers. There is th= erefore a variant with Lwt a= nd a variant with Miou. = However, we need to clarify a behaviour related to the use of Cachet. Readi= ng a file, whether with read(3) or mmap(3P), does= not block, but it can take some time.

    As we have already experienced and explained here, it may be necessary to explain to t= he scheduler whether it is appropriate to do something else after such a sy= scall. In the case of Lwt, it might be a good idea to insert Lwt.paus= e just after our syscall so that Lwt gives another service the oppor= tunity to run despite the time taken trying to read from a file. However, p= articularly for Lwt, this means closing Cachet in the hell of the monad (in= other words, there is no way to escape it) because of this possible = Lwt.pause (which returns unit Lwt.t).

    The composition of Cachet with Lwt is therefore quite different from what w= e've been able to experiment with. One of our other articles suggests not using func= tors (too much), and although we can in fact abstract Lwt.t fr= om unit Lwt.t (and even reduce it such that type 'a t = =3D 'a) with the HKP trick, we opted for comp= osition by hand.

    The problem relates to Lwt (and Async) and doesn't apply to Miou when it's = possible to raise effects. However, from such a composition, a choice has b= een made to give Lwt the opportunity to do something else after mmap<= /code>. We could, in other types of applications, make another choice on th= is precise question.

Carton

Carton is a library that was originally developed for ocaml-git. It was int= ernal to the project but we considered that the PACK format's field of appl= ication could be wider than that of Git. We decided to extract the project = from ocaml-git and make it a library in its own right. Carton'= s objective remains fairly rudimentary. It consists of:

  • extract objects from a PACK file (whether or not these objects are Git = objects)
  • generate an *.idx file from a PACK file in order to have q= uick access to the objects
  • verifying a PACK file such as git verify-pack does
  • and finally generate a PACK file from a list of objects

Carton is a library and a tool that you can now use on your Git repositorie= s. Here are a few examples of how to use carton. We'll start b= y cloning a repository to test Carton and go to the folder containing the P= ACK file. 

$ opam install carton.1.0.0
$ git clone https://github.com/ocaml/ocaml
$ cd ocaml/.git/objects/pack/

Carton can check a PACK file. Verifying means extracting all the objects in= the file from memory and calculating their hash. This command is similar t= o git verify-pack. 

$ carton verify pack-*.pack

Carton can extract a specific object (commit, tree or blob) from a PACK fil= e using its associated *.idx file and the object identifier (t= he hash of the commit, for example). 

$ carton get pack-*.idx 89055b054eeec0c6c6b6118d6490b6792da7fef2

Instead of extracting objects from a PACK file into memory, you can also ex= tract them as files using explode. 

$ mkdir loose
$ carton explode 'loose/%s/%s' pack-*.pack > entries.pack

Finally, Carton can create a new PACK file from a list of objects stored in= files with make. It can also generate the *.idx file associat= ed with the new PACK file. As we've just re-packaged the objects in the rep= ository, we should find the same objects. 

$ carton make -n $(cat entries.pack | wc -l) -e entries.pack new.pack
$ carton index new.pack
$ carton get new.idx 89055b054eeec0c6c6b6118d6490b6792da7fef2

Please note that the above actions, applied to ocaml/ocaml, ma= y take some time due to the history of this project.

In the example above, we can see the extraction of a Git object, the extrac= tion of all the objects in a PACK file and the creation of a new PACK file = based on all the extracted objects.

As you can see, creating a PACK file can take a long time. However, the adv= antage of the PACK file lies particularly in obtaining the objects and in t= he rate of compression of the PACK file: 

+--------+-------------+----------+-------+--------------+
|        | pack-*.pack | new.pack | loose | loose.tar.gz |
+--------+-------------+----------+-------+--------------+
|   size |        355M |     648M |  8.3G |         1.8G |
+--------+-------------+----------+-------+--------------+

The PACK file is primarily designed to provide access to objects according = to their identifiers. This access must be as fast as possible, even if the = object is first compressed with decompress and can be compressed in the for= m of a patch with duff. Here are a few metrics to give you an idea. 

+--------------+-------------+----------+---------+
|              | pack-*.pack | new.pack | loose   |
+--------------+-------------+----------+---------+
| git cat-file |     ~ 0.01s |      N/A |     N/A |
+--------------+-------------+----------+---------+
|   carton get |     ~ 0.20s |  ~ 0.30s |         |
+--------------+-------------+----------+---------+
|          cat |         N/A |      N/A | 0.0006s |
+--------------+-------------+----------+---------+

What's important to note is the ability to have random access to objects si= mply by having the associated *.idx file, the production of wh= ich is quite efficient. This is not or hardly the case for compression form= ats such as GZip. And that's the whole point of PACK files, with an indexin= g method for almost immediate access to objects according to their identifi= ers and offering a very good compression ratio.

NOTE: Carton does not compress the repository as well as Git. The ma= in reason is that Git has some heuristics relating to Git objects that Cart= on does not implement - because Carton wishes to be independent of Git conc= epts. These heuristics apply in particular to the order in which we want to= pack objects. In addition, Git prepares the ground so that the antecedents= of a blob object (which is a file in your repository), for example, are th= e old versions of that same blob (and therefore the old versions of your fi= le).

In this context, the patch algorithm implemented by duff applies very well and gives very good results.

For more details on these heuristics, you can read this= discussion that serves as documentation.

  • Carton & parallelism

    As always, our libraries are independent of schedulers. There is a version = of Carton with Lwt and a version with Miou.

    Some of the tasks Carton performs, such as indexing, are highly paralleliza= ble. In this case, the new derivation of Carton with Miou exists to take ad= vantage of the latter's domain pool.

    It was also quite easy to parallelize the work on carton index= and carton verify. Here are some other metrics which, thanks = to OCaml 5 and Miou, bring us closer to Git performance: 

    $ hyperfine \
  -n git \
    "git verify-pack pack-03a3a824757ff4c225874557c36d44eefe3d7918.idx" \
  -n carton \
    "carton verify pack-03a3a824757ff4c225874557c36d44eefe3d7918.pack -q --=
threads 4"
Benchmark 1: git
  Time (mean =C2=B1 =CF=83):     329.2 ms =C2=B1   0.9 ms    [User: 384.2 m=
s, System: 27.8 ms]
  Range (min =E2=80=A6 max):   327.7 ms =E2=80=A6 330.9 ms    10 runs
=20
Benchmark 2: carton
  Time (mean =C2=B1 =CF=83):     712.1 ms =C2=B1  10.9 ms    [User: 1111.8 =
ms, System: 1112.6 ms]
  Range (min =E2=80=A6 max):   695.4 ms =E2=80=A6 726.8 ms    10 runs
=20
Summary
  git ran
    2.16 =C2=B1 0.03 times faster than carton

    NOTE: it may come as a surprise that Carton is 2 times slower than G= it for analysing a PACK file, but it should be noted that almost the entire= Carton implementation is in OCaml! At this stage, the idea is more to give= you an idea, but we literally find ourselves comparing a Bugatti with a Citro=C3=ABn 2CV.

  • Carton & Emails

    Finally, this in-depth rewrite of Carton allows us to take advantage of the= PACK format for storing our emails.

    In fact, we are experimenting with and developing an email solution within = our cooperative, and email archiving is one of our objectives. Based on our= experience of implementing Git, we thought that the PACK format could be a= very interesting format for archiving emails.

    It combines two features, rapid access to emails and compression by patches= , which are very interesting when it comes to handling emails. Finally, it = also corresponds more or less to the way we use email:

    • we don't want to delete them (more often than not, we want to keep them= ad vitam aeternam)
    • and we don't modify them

    It therefore corresponds to a sort of read-only database. For more details = on this aspect of Carton and the results of our experiments, I suggest you = read our recent article on our cooperative's blog.

Opam repository archival, phase 2 - OCaml 4.08 is the lower bo= und

Archive: https://discuss.ocaml.org/t/opa= m-repository-arcival-phase-2-ocaml-4-08-is-the-lower-bound/15965/1

Hannes Mehnert announced

It is my pleasure to announce below the list of opam packages that will mov= e to the opam-repository-archive on February 1st 2025. In total there are 5= 855 opam files scheduled for being moved within 1218 unique packages. This = decreases the size of the opam-repository by roughly 20%.

Editor note: please follow the post link for the other articles with who= le list.=20=20=20=20=20=20=20=20

This list contains all packages that are not compatible with OCaml >=3D = 4.08, and packages that after archiving those are not installable due to mi= ssing dependencies. The "not installable" list has been generated by archive-opam, and this ma= y of course contain bugs.

A smaller list contains a re-run of phase 1 (packages that are available: f= alse) - where the availability was added between Dec 15th and now.

If you find a package in the list and you=E2=80=99d like to retain it in th= e opam-repository, there are some options:

  • (a) you can install it on your system (opam install): this= means there=E2=80=99s a bug in the archive-opam utility, please provide th= e package name and version in the opam-repository-archive Phase 2 PR, together= with your opam version, OCaml version, and operating system;
  • (b) it is not installable: please figure out the reasoning (the =E2=80= =9CReasoning=E2=80=9D may help you to find the root issue), and try to fix = it yourself - if you=E2=80=99re unable to fix the root cause, please also c= omment in the opam-repository-archive Phase 2 PR with the package name and ver= sion.

If you=E2=80=99ve any questions, please don=E2=80=99t hesitate to ask here = or on GitHub or via another communication channel.

You can help further on the archiving process:

  • as mentioned in the last announcement please add the x-maintenanc= e-intent to your packages (a good choice for a lot of packages is x-maintenance-intent: [("latest")] if you=E2=80=99re maintaining= the latest version only) - this will be considered in Phase 3 (March 1st 2= 025);
  • if you are the author or maintainer of a package that is no longer usef= ul or maintained, you can as well mark your opam files in the opam-reposito= ry with x-maintenance-intent: [("none")] (this will be taken i= nto account in Phase 3 - March 1st 2025);
  • if you flagged your preliminary releases with flags: avoid-versio= n, and they can now be removed (e.g. since a stable version has been= released), please open a pull request to replace the avoid-version with deprecated.

Please note that the next Phase will be announced on February 15th with all= packages where the x-maintenance-intent does not match, and w= hich do not have any reverse dependencies - archiving is scheduled for Marc= h 1st.

To keep track of the announcements, please look at the opam-repository tag.

A big thanks to the OCaml Software Foundation for funding the opam-reposito= ry archival project.

Ocaml-posix 2.1.0 released!

Archive: https://discuss.ocaml.org/t/ocaml-posix-2-1-0-released/15974/1

Romain Beauxis announced

Hi all!

Version 2.1.0 of ocaml-posix has been released!

While it was long overdue, this version only include minor changes, along w= ith the addition of posix-math2.

These packages are intended to provide a consistent, extensive set of bindi= ngs for the various POSIX APIs to be used with ocaml-ctypes when building bindings to C librari= es that require the use of these APIs.

While working on OCaml projects, it is common to have to interface with API= s derived from the POSIX specifications, getaddrinfo, un= ame etc.

The core OCaml library provides their own version of these APIs but:

  • They only cover parts of it
  • They wrap some native types such as socketaddr into custom= , opaque OCaml types, making it impossible to re-use, for instance when usi= ng a C library API requiring a POSIX sockaddr.

Thus, having a large, consistent set of bindings for these APIs that reflec= t the actual C types, structures and etc greatly improves the usability of = the language and ecosystem as a whole by making it possible to interface it= with a large set of C libraries in a reusable way.

The project has been mostly stable for a couple of years (and so have the P= OSIX standards), but could use some more hands if there is more need in the= community to extend the set of POSIX APIs supported by the language.

Release of ocaml-eglot 1.0.0

Archive: https://discuss.ocaml.org/t/ann-release-of-ocaml-eglot-1-0-0= /15978/1

Xavier Van de Woestyne announced

Hi everyone!

We (at Tarides) are particularly pleased to announce the first release of OCaml-eglot, An overlay on= Egl= ot (the built-in LSP client for Emacs) for = editing OCaml!

More precisely

Typically, developers who use Emacs (43.7% in 2022, according to th= e OCaml User Survey) use a major mode (such as the venerable caml-mode, or tuareg) and Merlin to provide IDE services. In 2016, Microsoft has release= d LSP, a generic protocol for interacting with editors which, at first, was= only used by Visual Studio Code, but, since 2020, has really become the no= rm. De-facto, following the LSP standard gives very good default (completion, jump to definition, …). OCaml ha= s excellent LSP (oc= aml-lsp-server) support, which is used in particular by the OCaml platform for Visual Studio Code.

With the aim of reducing maintenance for all possible editors, going LSP se= ems to be a good direction. A pertinent choice, especially since the major = historical editors (such as Vim and Emacs) offer, in their recent versions,= LSP clients out of the box. However, in t= he same way that the OCaml client for VSCode integrates OCaml-specific features, it was necessary to support these features on the Emacs side (= and in the future, Vim) to compete with Merlin, which is the goal of = ocaml-eglot, to provide a tailored development experience for OCa= ml code editing!

User feedback and future development

We've just released the first version of OCaml-eglot, and, much like the va= rious editor-related projects (Merlin, Vscode-ocaml-platform, Merlin for Em= acs, Merlin for Vim), we're more than open to community collaboration, u= ser feedback, in order to provide the best possible user experience!

Happy Hacking!

Semgrep is hiring to help scale their static analysis engine

Archive: https://discuss.ocaml= .org/t/job-remote-semgrep-is-hiring-to-help-scale-their-static-analysis-eng= ine/15982/1

Emma Jin announced

Semgrep is an application security company focused on detecting and remedia= ting vulnerabilities. The static analysis engine is primarily written in OC= aml. We're looking for a software engineer to help us support scanning larg= er repositories and add many more users. The ideal candidate has owned a cr= itical tool, worked on an OCaml project, and is interested in static analys= is.

If this sounds interesting to you, see our job posting at https://job-boards.gree= nhouse.io/semgrep/jobs/4589941007! Let me know if you have any question= s!

Dune dev meeting

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

Etienne Marais announced

Hi Dune enthusiasts :camel:,

We will hold the regular Dune Dev Meeting on Wednesday, January, 22nd at= 16:00 CET. As usual, the session will be one hour long.

Whether you are a maintainer, a regular contributor, a new joiner or just c= urious, you are welcome to join: these discussions are opened! The goal of = these meetings is to provide a place to discuss the ongoing work together a= nd synchronize with the Dune developers!

:calendar: Agenda

The agenda is available on the meeting dedicated page. Feel free to ask if y= ou want to add more items in it.

:computer: Links

Tarides: 2024 in Review

Archive: https://discuss.ocaml.org/t/tarides-2024-in-review/15990/1

Thomas Gazagnaire announced

At Tarides, we believe in making OCaml = a mainstream programming language by improving its tooling and integration = with other successful ecosystems. In 2024, we focused our efforts on initia= tives to advance this vision by addressing key technical challenges and eng= aging with the community to build a stronger foundation for OCaml=E2=80=99s= growth. This report details our work, the rationale behind our choices, an= d the impact achieved. We are very interested in getting your feedback: please get in touch (or respond t= o this thread!) if you believe we are going in the right direction.

TL;DR = =E2=80=93 In 2024, Tarides focused on removing adoption friction with bette= r documentation and tools; and on improving adoption via the integration wi= th three key thriving ecosystems: multicore programming, web development, a= nd Windows support. Updates to ocaml.org i= mproved onboarding and documentation, while the Dune Developer Preview simplified workflows with integrate= d package management. Merlin added support for project-wide reference support and odoc 3, which is about to b= e released. OCaml 5.3 marked the first stable multicore release, and = js_of_ocaml achieved up to 8x performance boosts in real-world comme= rcial applications thanks to added support for WebAssembly. On Windows, opa= m 2.2 brought full compatibility and CI testing to all Tier 1 platforms on = opam-repository, slowly moving community packages towards reli= able and better support for Windows. Tarides=E2=80=99 community support inc= luded organising the first FUN OCaml con= ference, many local meetups, and two rounds of Outreachy internships.

Better Tools: Toward a 1-Click Installation of OCaml<= /h4>

Our primary effort in 2024 was to continue delivering on the OCaml Platform roadmap published= last year. We focused on making it easier to get started with OCaml by re= moving friction in the installation and onboarding process. Our priorities = were guided by the latest OCSF User Survey, direct user interviews, and <= a href=3D"https://discuss.ocaml.org/tag/user-feedback">feedback gathere= d from the OCaml community. Updates from Tarides and other OCaml Platform m= aintainers were regularly shared in the OCaml Platform Newsletter.

  • OCaml.org

    OCaml.org is the main entry point for new users of OCaml. Tarides engineers= are key members of the OCaml.org team. Using privacy-preserving analytics, the team tracked visito= r behaviour to identify key areas for improvement. This led to a redesign o= f the installation page, simplify= ing the setup process, and a revamp of the guided tour of OCaml to better introduce the language.= Both pages saw significant traffic increases compared to 2023, with the in= stallation page recording 69k visits, the tour reaching 65k visits and a ve= ry encouraging total number of visits increasing by +33% between Q3 and Q4 = 2024

    3D"137aea463013b316=

    Efforts to improve user experience included a satisfaction survey where 75%= of respondents rated their experience positively, compared to 17% for the = previous version of the site. User testing sessions with 21 participants pr= ovided further actionable insights, and these findings informed updates to = the platform. The redesign of OCaml.org community sections was completed us= ing this feedback. It introduced several new features: a new Community landing page, an academic institutions page with course listi= ngs, and an industrial users= showcase. The team also implemented an automated event announcement system to inform the community of on= going activities.

    Progress and updates were regularly shared through the OCaml.org newsletters, keepin= g the community informed about developments. Looking ahead, the team will c= ontinue refining the platform by addressing feedback, expanding resources, = and monitoring impact through analytics to support both new and experienced= OCaml users. Lastly, the infrastructure they build is starting to be used = by other communities: Rocq just an= nounced their brand new website, built using the same codebase as ocaml.org!

  • Dune as the Default Frontend of the OCaml Plat= form

    One of the main goals of the OCaml Platform is to make it easier for users= =E2=80=94especially newcomers=E2=80=94to adopt OCaml and build projects wit= h minimal friction. A critical step toward this goal is having a single CLI= to serve as the frontend for the entire OCaml development experience (code= named Bob in the past). This year, we made significant progress in that di= rection with the release of the Dun= e Developer Preview.

    Setting up an OCaml project currently requires multiple tools: opam for package management, dune for builds, and additional = installations for tools like OCamlFormat or Odoc. While powerful, this frag= mented workflow can make onboarding daunting for new users. The Dune Develo= per Preview consolidates these steps under a single CLI, making OCaml more = approachable. With this preview, setting up and building a project is as si= mple as:

    1. dune pkg lock to lock the dependencies.
    2. dune build to fetch the dependencies and compile the proje= ct.

    This effort is also driving broader ecosystem improvements. The current OCa= ml compiler relies on fixed installation paths, making it difficult to cach= e and reuse across environments, so it cannot be shared efficiently between= projects. To address this, we are working on making the compiler relocatab= le (ongoing work). This = change will enable compiler caching, which means faster project startup tim= es and fewer rebuilds in CI. As part of this effort, we also maintain p= atches to core OCaml projects to make them relocatable =E2=80=93 and we wor= ked with upstream to merge (like for ocamlfind). Tarides engineers also continued to mainta= in Dune and other key Platform projects, ensuring stability and progress. T= his included organising and participating in regular development meetings (= for Dune, opam, = Merlin, ppxlib, etc.) to prioritise community needs and align efforts acr= oss tools like Dune and opam to avoid overlapping functionality.

    The Dune Developer Preview is an iterative experiment. Early user feedback = has been promising (the Preview=E2=80=99s NPS went from +9 in Q3 2024 to +2= 7 in Q4 2024), and future updates will refine the experience further. We ai= m to ensure that experimental features in the Preview are upstreamed into s= table releases once thoroughly tested. For instance, the package management= feature is already in Dune 3.17. We will announce and document it more wid= ely when we believe it is mature enough for broader adoption.

  • Editors

    In 2024, Tarides focused on improving editor integration to lower barriers = for new OCaml developers and enhance the experience for existing users. Edi= tors are the primary way developers interact with programming languages, ma= king seamless integration essential for adoption. With more than 73% of developers using Visual Studio Code (VS Code), VS Co= de is particularly important to support, especially for new developers and = those transitioning to OCaml. As part of this effort, Tarides wrote and mai= ntained the official VS Code plugin for OCaml, priorit= ising feature development for this editor. We also support other popular ed= itors like Emacs and Vim=E2=80=94used by many Tarides engineers=E2=80=94on = a best-effort basis. Improvements to OCaml-LSP and Merl= in, both maintained by Tarides, benefit all supported editors, ensuring= a consistent and productive development experience.

    3D"9b63754a94bc853f=

    While several plugins for OCaml exist (OCaml and Reason IDE=E2=80=93128k installs, Hackwaly=E2=80=9390k installs), our OCaml VS Code plugin =E2=80=93now with over 208k downloads= =E2=80=93 is a key entry point for developers adopting OCaml in 2024. This = year, we added integration with the Dune Developer Preview, allowing users = to leverage Dune's package management and tooling directly from the editor.= Features such as real-time diagnostics, autocompletion, and the ability to= fetch dependencies and build projects without leaving VS Code simplify dev= elopment and make OCaml more accessible for newcomers.

    The standout update in 2024 was the addition of project-wide reference support, a long-requested featu= re from the OCaml community and a top priority for commercial developers. T= his feature allows users to locate all occurrences of a term across an enti= re codebase, making navigation and refactoring significantly easier=E2=80= =94especially in large projects. Delivering this feature required coordinat= ed updates across the ecosystem, including changes to the OCaml compiler, M= erlin, OCaml LSP, Dune, and related tools. The impact is clear: faster navi= gation, reduced cognitive overhead, and more efficient workflows when worki= ng with complex projects.

    Additional improvements included support for new Language Server Protocol f= eatures, such as signature_help and inlay_hint, w= hich enhance code readability and provide more contextual information. Thes= e updates enabled the introduction of new commands, such as the "Destruct" = command. This little-known but powerful feature au= tomatically expands a variable into a pattern-matching expression correspon= ding to its inferred type, streamlining tasks that would otherwise be tedio= us.

    3D"merlin-destruct-1~kHA8_=

  • Documentation

    Documentation was identified as the number one pain point in the latest OCSF = survey. It is a critical step in the OCaml developer journey, particula= rly after setting up the language and editor. Tarides prioritised improving= odoc to make it easier for developers to find information, le= arn the language, and navigate the ecosystem effectively. High-quality docu= mentation and tools to help developers get "unstuck" are essential to reduc= ing friction and ensuring a smooth adoption experience.

    Tarides is the primary contributor and maintainer of odoc, OCaml=E2=80=99s main documentati= on tool. In preparation for the odoc 3 release, our team introduced two significan= t updates. First, the odoc= Search Engine was integrated, allowing developers to search dir= ectly within OCaml documentation via the Learn page. Second, the = odoc Cheatsheet provides a concise reference for creating = and consuming OCaml documentation. We would like to believe that these upda= tes, deployed on ocaml.org, were the main cause of a 45% increase in = package documentation usage on h= ttps://ocaml.org/pkg/ in Q4 2024!

    3D"a974b30576399d84=

    Another area where developers often get stuck is debugging programs that do= n=E2=80=99t work as expected. Alongside reading documentation, live debugge= rs are crucial for understanding program issues. Tarides worked to improve = native debugging for OCaml, focusing on macOS, where LLDB is the only suppo= rted debugger. Key progress included a name mangling fix to improve symbol resolution, resto= ring ARM64 backtraces, and introducing Python shims for code sharing betwee= n LLDB and GDB.

    OCaml=E2=80=99s error messages remain a common pain point, particularly for= syntax errors. Unlike Rust=E2=80=99s error index, OCaml does not (yet!) have a= centralised repository of error explanations. Instead, we are focused on m= aking error messages more self-explanatory. This requires developing new to= ols, such as lrgrep, a domain-specific language for analysing grammars built with Menhi= r. lrgrep enables concise definitions of error cases, making i= t possible to identify and address specific patterns in the parser more eff= ectively. This provides a practical way to improve error messages without r= equiring changes to the compiler. In December 2024, @let-def successfully d= efended his PhD (a collaboration between Inria and Tarides) on this topic, = so expect upstreaming work to start soon.

  • OCaml Package Ecosystem

    The last piece of friction we aimed to remove in 2024 was ensuring that use= rs wouldn=E2=80=99t encounter errors when installing a package from the com= munity. This required catching issues early=E2=80=94before packages are acc= epted into opam-repository and made available to the broader e= cosystem. To achieve this, Tarides has built and maintained extensive CI in= frastructure, developed tools to empower contributors, and guided package a= uthors to uphold the high quality of the OCaml package ecosystem.

    In 2024, Tarides=E2=80=99 CI infrastructure supported the OCaml community a= t scale, handling approximately 20 million jobs on 68 machines coveri= ng 5 hardware architectures. This infrastructure continuously teste= d packages to ensure compatibility across a variety of platforms and config= urations, including OCaml=E2=80=99s Tier 1 platforms: x86, ARM, RISC-V, s39= 0x, and Power. It played a critical role during major events, such as new O= Caml releases, by validating the ecosystem=E2=80=99s readiness and catching= regressions before they impacted users. Additionally, this infrastructure = supported daily submissions to opam-repository, enabling contr= ibutors to identify and resolve issues early, reducing downstream problems.= To improve transparency and accessibility, we introduced a CI pipeline tha= t automates configuration updates, ensuring seamless deployments and allowi= ng external contributors to propose and apply changes independently.

    In addition to maintaining the infrastructure, Tarides developed and mainta= ined the CI framework running on top of it. A major focus in 2024 was makin= g CI checks available as standalone CLI tools distributed via opam. These tools enable package authors to run checks locally, empowering = them to catch issues before submitting their packages to opam-reposit= ory. This approach reduces reliance on central infrastructure and al= lows developers to work more efficiently. The CLI tools are also compatible= with GitHub Actions, allowing contributors to integrate tests into their o= wn workflows. To complement these efforts, we enhanced opam-repo-ci, which remains an essential safety net for packages entering the repo= sitory. Integration tests for linting and reverse dependencies were introdu= ced, enabling more robust regression detection and improving the reliabilit= y of the ecosystem.

    To uphold the high standards of the OCaml ecosystem, every package submissi= on to opam-repository is reviewed and validated to ensure it m= eets quality criteria. This gatekeeping process minimises errors users migh= t encounter when installing community packages, enhancing trust in the ecos= ystem. In 2024, Tarides continued to be actively inv= olved in maintaining the repository, ensuring its smooth operation. We = also worked to guide new package authors by updating the contributing= guide and creating a detailed wiki with actionable instructions for adding and main= taining packages. These resources were announced on Discuss to reach the community and simplify the p= rocess for new contributors, improving the overall quality of submissions.

Playing Better with the Larger Ecosystem

  • Concurrent & Parallel Programming in OCaml=

    "Shared-memory multiprocessors have never really = 'taken off', at least in the general public. For large parallel computation= s, clusters (distributed-memory systems) are the norm. For desktop use, mon= oprocessors are plenty fast." – Xavier Leroy, November 200= 2

    Twenty+ years after this statement, processors are multicore by default, an= d OCaml has adapted to this reality. Thanks to the combined efforts of the = OCaml Labs and Tarides team, the OCaml 5.x series introduced multicore supp= ort after a decade of research and experime= ntation. While this was a landmark achievement, the path to making mult= icore OCaml stable, performant, and user-friendly has required significant = collaboration and continued work. In 2024, Tarides remained focused on meet= ing the needs of the broader community and commercial users.

    OCaml 5.3 (released last week) was an important milestone in this journey. = With companies such as Routine, Hyper, and Asemio adopting OCaml 5.x, and advanced experimentation ongoing at J= ane Street, Tezos, Semgrep, and others, OCaml 5.3 is increasingly seen as t= he first =E2=80=9Cstable=E2=80=9D release of the multicore series. While so= me performance issu= es remain in specific parts of the runtime, we are working closely with= the community to address them in OCaml 5.4. Tarides contributed extensivel= y to the 5.2 and 5.3 releases by directly contrib= uting to nearly two-thirds of the merged pull requests. Since= Multicore OCaml was incorporated upstream in 2023, we have been continuous= ly involved in the compiler and language evolution in collaboration with In= ria and the broader OCaml ecosystem.

    Developing correct concurrent and parallel software is inherently challengi= ng, and this applies as much to the runtime as to applications built on it.= In 2024, we focused on advanced testing tools to help identify and address= subtle issues in OCaml=E2=80=99s runtime and libraries. The property-based test suite reached maturity this year, uncovering over 40 critical issues, with 28 = resolved by Tarides engineers. Trusted to detect subtle bugs, such as is= sues with orphaned ephemerons, the suite has become an integral part of= OCaml=E2=80=99s development workflow. Importantly, it is accessible to con= tributors without deep expertise in multicore programming, ensuring any cha= nges in the compiler or the runtime do not introduce subtle concurrency bug= s.

    3D"false-alarms-plot-errors-only.png"

    Another critical effort was extending ThreadSanitizer (TSAN) support to mos= t Tier 1 platforms and applying it extensivel= y to find and fix data races in the runtime. This work has improved the= safety and reliability of OCaml=E2=80=99s multicore features and is now pa= rt of the standard testing process, further ensuring the robustness of the = runtime.

    Beyond testing, we also worked to enhance library support for multicore pro= gramming. The release of the Saturn library introd= uced lock-free data structures tailored for OCaml 5.x. To validate these st= ructures, we developed DSCheck, a static analyser for verify= ing lock-free algorithms. These tools, along with Saturn itself, provide de= velopers with reliable building blocks for scalable multicore applications.

    Another promising development in 2024 was the introduction of the Picos= framework. Picos aims to provide a low-level foundation for concurrency, s= implifying interoperability between libraries like Eio, Moonpool, Miou, Rio= t, Affect, etc. Picos offers a simple, unopinionated, and safe abstraction = layer for concurrency. We believe it can potentially standardise concurrenc= y patterns in OCaml, but we are not there yet. Discussions are underway to = integrate parts of Picos into higher-level libraries and, eventually, the s= tandard library. We still have a long way to go, and getting feedback from = people who actively tried it in production settings would be very helpful!

  • Web

    Web development remains one of the most visible and impactful domains for p= rogramming languages; JavaScript, HTML, and CSS are the= most popular technologies in 2024. For OCaml to grow, it must integrat= e well with this ecosystem. Fortunately, the OCaml community has already bu= ilt a solid foundation for web development!

    On the frontend side, in 2024, Tarides focused on strengthening key tools l= ike js_of_ocaml by expanding its support for WebAssembly (Wasm). js_of_ocaml= (JSOO) has long been the backbone of OCaml=E2=80=99s web ecosystem,= enabling developers to compile OCaml bytecode into JavaScript. This year, = we merged Wasm= support back into JSOO, unifying the toolchain and simplifying adoptio= n for developers. The performance gain of Wasm has been very impressive so = far: CPU-intensive applications in commercial settings have seen 2x t= o 8x speedups using Wasm compared to traditional JSOO. We also work= ed on better support for effect handlers in js_of_ocaml to ens= ure applications built with OCaml 5 can run as fast in the browser as they = used to with OCaml 4.

    On the backend side, Tarides maintained and contributed to Dream, a lightwe= ight and flexible web framework. Dream powers projects like our own website and the MirageOS website, where we maintain a fork to make Dream and Mirage= OS work well together. Additionally, in 2024, we enhanced cohttp, adding prox= y support to address modern HTTP requirements.

    While Tarides focused on JSOO, wasm_of_ocaml, Dream, and Cohtt= p, the broader community made significant strides elsewhere. Tools like Mel= ange offer an alternative for compiling OCaml to JavaScript, and frameworks= like Ocsigen, which integrates backend and frontend programming, continue = to push the boundaries of what=E2=80=99s possible with OCaml on the web. No= tably, Tarides will build on this momentum in 2025 through a grant to improve direct-style= programming for Ocsigen.

  • Windows

    Windows is the most widely used operating system, making first-class suppor= t for it critical to OCaml=E2=80=99s growth. In 2024, 31% of visitors= to ocaml.org accessed the site f= rom Windows, yet the platform=E2=80=99s support historically lagged behind = Linux and macOS. This gap created barriers for both newcomers and commercia= l users. We saw these challenges firsthand, with Outreachy interns struggli= ng to get started due to tooling issues, and commercial users reporting dif= ficulties with workflow reliability and compilation speed.

    To address these pain points, Tarides, in collaboration with the OCaml comm= unity, launched the Windows Working Group. A key milest= one that our team contributed to was the release this year of opam 2.= 2, three years after its predecessor. This release made the upstrea= m opam-repository fully compatible with Windows for the first = time, removing the need for a separate repository and providing Windows dev= elopers access to the same ecosystem as Linux and macOS users. The impact h= as been clear: feedback on the updated installation workflow has been overw= helmingly positive, with developers reporting that it "just works." The install page for Windows is now sign= ificantly shorter and simpler!

    In the OCaml 5.3 release, Tarides restored the MSVC Windows port, ensuring = native compatibility and improving performance for Windows users. To furthe= r support the ecosystem, Tarides added Windows machines to the opam infrast= ructure, enabling automated testing for Windows compatibility on every new = package submitted to opam. This has already started to improve package supp= ort, with ongoing fixes from Tarides and the community. The results are pub= licly visible at windows.check.ci= .dev, which we run on our infrastructure, providing transparency and a = way to track progress on the status of our ecosystem. While package support= is not yet on par with other platforms, we believe that the foundations la= id in 2024=E2=80=94simplified installation, improved tooling, and continuou= s package testing=E2=80=94represent a significant step forward.

Community Engagement and Outreach

In 2024, Tarides contributed to building a stronger OCaml community through= events, internships, and support for foundational projects. The creation o= f FUN OCaml 2024 in Berlin was the f= irst dedicated OCaml-only event for a long time (similar to how the OCaml W= orkshop was separated from ICFP in the past). Over 75 participants joined f= or two days of talks, workshops, and hacking, and the event has already rea= ched 5= k+ views on YouTube. Tarides also co-chaired the OCaml Workshop at ICFP 2024 in Milan, bringing togeth= er contributors from academia, industry, and open-source communities. These= events brought together two different kinds of OCaml developers (with some= overlap), bringing an interesting energy to our community.

To expand local community involvement, Tarides organised OCaml hacking meet= ups in Manila and Chennai. To make it easier for others to = host similar events, we curated a list of interesting hacking issues from p= ast Cambridge sessions, now available on GitHub.

As part of the Outreachy program, Tarides supported two rounds of internshi= ps in 2024, with results published on Discuss and watch.oc= aml.org. These internships not only provided great contributions to our= ecosystem but also brought fresh insights into the challenges faced by new= users. For example, interns identified key areas where documentation and t= ooling could be improved, directly informing future updates.

Tarides also maintained its commitment to funding critical open-source proj= ects and maintainers. We continued funding Robur for their maintenance work on MirageOS= (most of those libraries are used by many =E2=80=93including us=E2=80=93 e= ven in non-MirageOS context) and Daniel B=C3=BCnzli, whose libraries like cmdliner a= re essential for some of our development.

Finally, Tarides extended sponsorships to non-OCaml-specific events, includ= ing JFLA, BobConf, FSTTCS, and Terminal Feud (which garnered over 100k views). These events expande= d OCaml=E2=80=99s visibility to new audiences and contexts, introducing the= language to a broader technical community that =E2=80=93we hope=E2=80=93 w= ill discover OCaml and enjoy using it as much as we do.

What=E2=80=99s Next?

As we begin 2025, Tarides remains committed to making OCaml a mainstream la= nguage. Our focus this year is to position OCaml as a robust choice for mis= sion-critical applications by enhancing developer experience, ecosystem int= egration, and readiness for high-assurance use cases.

We aim to build on the Dune Developer Preview to further improve usability = across all platforms, with a particular emphasis on Windows, to make OCaml = more accessible to a broader range of developers. Simultaneously, we will e= nsure OCaml is ready for critical applications in industries where reliabil= ity, performance, and security are essential. Projects like SpaceOS showcase the potential of memory- and type-safe languages for safety-crit= ical systems. Built on MirageOS and OCaml=E2=80=99s unique properties, Spac= eOS is part of the EU-funded Orch= ide project and aims to set a new standard for edge computing in space.= Additionally, SpaceOS is being launched in the US through our spin-off Parsimoni. However, these needs are not l= imited to Space: both the EU Cyber Resilience Act and the US cybersecurity initiatives= highlight the growing demand for type-safe, high-assurance software to= address compliance and security challenges in sensitive domains. Tarides b= elieves that OCaml has a decisive role to play here in 2025!

I=E2=80=99d like to personally thank our sponsors and customers, especially= Jane Street, for their unwavering support over the years, and to Dennis Dang, our single recurring Gi= tHub sponsor. Finally, to every member of Tarides who worked so hard in 202= 4 to make all of this happen: thank you. I=E2=80=99m truly lucky to be sail= ing with you on this journey!

We are looking for spons= ors on GitHub, are happy to collaborate on innovative projects involving OCaml or MirageOS and off= er commercial services for op= en-source projects =E2=80=93 including long-term support, development of ne= w tools, or assistance with porting projects to OCaml 5 or Windows.

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.

--=-=-=--