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=q+5uonQs; 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=WxXL0huB; 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 9EF804AA88 for ; Tue, 3 Dec 2024 14:44:18 +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=CGarx75hbgssUuPT9UADYPMS/859Q3sM8GX26LE2ES8=; b=q+5uonQsrhxdVoXLgMmCUwuDaGb2kwsm/NOfk+Fy07XfxcLAZuJFgOtc JQui1OoBhl3tSCo8ramR+++NB6Biayqf0fmZbkWZcWubdsP4HJJqcVCjM RUZDUw18Vj1ICFnJuaCyfCuheNq778mL34x48TT/GdyJnChowIj3TEme2 0=; 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.12,205,1728943200"; d="scan'208,217";a="197118357" Received: from prod-listesu18.inria.fr (HELO sympa.inria.fr) ([128.93.162.160]) by mail2-relais-roc.national.inria.fr with ESMTP; 03 Dec 2024 15:44:16 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id 5CBF1E0D24; Tue, 3 Dec 2024 15:44:16 +0100 (CET) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id E8000E00B6 for ; Tue, 3 Dec 2024 15:44:12 +0100 (CET) IronPort-SDR: 674f193a_90nbYWhroz+aYNZgo7jGjdjrRoJHMAKYTLe2iqDw0GUtStz vPFGXngK2vzmNi3NXKvhjVk/z0d2v+BXH7JlPgQ== X-IPAS-Result: =?us-ascii?q?A0E6DgAFGE9ngSIeaIFQChaCSIE/WygZAV0GWjMHCEhhg?= =?us-ascii?q?3WDT4s/gmCBFpA3ineCewMYFiMUAQMBDS4BBQ0BAgQBAQMBAgGCDIIuRgKKa?= =?us-ascii?q?AIfBgEENBMBAgQBAQEBAwIDAQEBAQEBEAEBBQEBAQIBAQIEBgECEAEBPQVJh?= =?us-ascii?q?XsNSQEBAQECAQEJAYFqUXFhBAMGNwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQIIBAEwElwBAgYEBhMBASkCDRgjAxAEAQYDA?= =?us-ascii?q?hEBNRcBCQkUBQEBgg5Zgh9FAwQBDAaUaptLen8zgQGCDAEBBoEIPgIBCwICA?= =?us-ascii?q?wEOCSUB1zeCT4EaSgmBMBiFaoJIGgEFJUhqAoRGCYMUJHkCJw+BVUSBFYIoL?= =?us-ascii?q?xsHb4FQLgY7CxcBAQEBAReBGQQHAQEIRQmDJYJpgicKEi1MOwIHgl92IwJNR?= =?us-ascii?q?oNzLgOBXl6BDYFvgg+DNBJWgVx5gSApgRgdHTALO4EPWYExBIoAgUciAyYzM?= =?us-ascii?q?gFVExcLBwVhgRYDgXqBTYE2gVFDgk5KhQyBAzmCEWlNOgINAjaCJCRZgk2DW?= =?us-ascii?q?IE/hGmEW4YsYR1AAwttPTcUG6B/AQkzaQFGglILJA4KAS0GAQEVBUYaCQoIA?= =?us-ascii?q?xEIBgEBIAINHgEBCQULEwoHBQcCAQICJggEBAIDBQkCAgwFBgEBDhQLCwsCL?= =?us-ascii?q?QONCIU1FBAUBAUeB3eOTINUij2Tb200B4QdgV0GDIkEgSSOLYdNhASBV4suh?= =?us-ascii?q?wCLBodCIphZIoI1hyVdSAmBbh5MiQmMSggZGIUdgX4jgSseDAczGjBDgjMBA?= =?us-ascii?q?QExCUYcD1eNUwIBFoMwKIE+gSEFgTw5O70JLwJCNQIBAQcxAgcBCgEBAwmFR?= =?us-ascii?q?R0BAYVzgRGCRQKCBQImBwVqYQEB?= IronPort-PHdr: A9a23:Wz7EhRWOO1OHn4FvJqgzp0OJazTV8Kx/WzF92vMcY1JmTK2v8tzYM VDF4r011RmVBtydtakP0Lqe8/i5HzBbudDZ6DFKWacPfiFGoP1VpTBoONSCB0z/IayiRA0BN +MGamVY+WqmO1NeAsf0ag6aiHSz6TkPBke3blItdaz6FYHIksu4yf259YHNbAVUnjq9Zq55I AmroQnLucQbj5ZuJrwwxxbHrXdFdedbzn5sKV6Pghrw/Mi98ZB//yhKp/4t68tMWrjmcqolS rBVEDspP2cp6cPxshXNURWB7WYGXGUMlRpIDQnF7BXkUZr0ryD3qOlz1jSEMMPvVbw7Viis4 KltSB/zlScILCU5/33Nisxxl61UvhSsrAFizoHOYYGVMP1+fr7Bfd4fWGFMUNpdWzBHD4iha IQBEvcBPf1Ar4bju1QOsRWwBQ6pBOz1yz9IgGL90ak13uklFA3L2hErEdATv3TOtNj7NLkcX /27wqfLwjrMc+hb1i3h5IXSaB0tve2AULB2fMHMyUcvDQTFjlCIpIH5OzOazOINuHWG4eV8V eKvjm8nqx1tojOywcojkI3JiZgTylze7iV23IY1Jdi5SE5nfd6pC4NQtyaeN4p2XsMtXX1nu CY8yr0HoJ67YTYFxI4gxx7FZPyKao6F6Q/sW+iNOzl3nm5leK6hiBao90it0uPxW9e63ltXo SdLncfAu20M2hHX6cWKSvlw8luv1DuR1w3e9v1ILV0omabGJZMs3LA+m5QTvEnNHyL7mUH7g LOQe0459Oao7OHnba/npp+aL4J0kh/xMrgvmsyjH+s4Kg8OX22e+euizrHj+1P2QKlSgv0xj qbWqpXaJcABqq6+GQ9V3Z4v5AqlDzi83tQYgXgHLFRKeBKGiYjpJ0/BIOrgDfelnVusjClkx +rdPrH7HprNKX3DnK/ufbZ8905cyBczwstF651IDbEBJer/VVP0tNPCFB85MA20w/r9BNV40 oMSQWGPDbGdMKzMql+I5vwgI/eWaIAJvzb9LuAp5vDvjX86mF8dZbem0oYWaH+iBPhmJF+ZY XX0jtYBFmcKoxY+TPHxh1KcSzJce3GyX6ck6jEgCIOmC5vDSZqigbCb2Se7GoVaZmVcBVCWE nfoap2EV+0JaCKWOsNhkiAEVb2lS4A5yRGuswz6xKRhLurV+ywXq4jj2MJw5+3XjR0y9SB0D 8GZ026VV2F7hHkIRyQo06Blu0B9z1OD3bB5g/xeD9xT5ulGXh00NZ7G1+B1F9DyVRjHfteGV lmmWc+qATQsQd4pwt4OZ0d9FM64ghDFwSWqH6cZlr2QBJwo763QxX7xKNhhy3rez6Yhi0MpQ shROmConKJ/9g/TC5bJk0qDiqmqb6Mc3CjW9GuZymqOpk5YXBZ/UKTKXXAQfFDWrdTj6kzeS L+uDKwrPRVbyc6YMKRKdtzpjUxbRPj9ItjRf2Kxl3+3BRmU3LyMaY7qd3wG3CXTEkQElBoT/ XmeOQgxByehv2LeDCF1Gl71YkPs9vFyp220T08s0Q6Fc1Fh2KSo9RIPhPycTe8T0qoDuCg9s DV0HVm90MzQC9aaoAphZqpcbcsy4FdGyWLZsxZyMYe6I6BjgV4Sawt3v0Ly1xVzEIpPitImo 28tzAp3Ma6YyFdBeCmE3ZD+Pb3XMGzy/Au1Z67Tx17SyMyZ+r0T5/Q4qlXjogCpFkwt83l91 tlazn2R7YjJAgoKSZ/9T1g7+hxgq73HfiUw6JnY2HNwPaWuvDLP1MolCeg7xhq6ftpSMbmIG BH9HsEGHcSjJ/Emll60ZR8aOOBS6bU0P9+4ePucxaCrPedhkyy+gGhb5o12z1iC+DBmSuHS2 pYI2/GY0RWDVzf7lFqht8/2lZ1eaTEKGWq/zSjlBJJPaaJufYYLD2auI9SqxtpgnZLtXGRY9 FG7C1MH3s+mZwaSYkTg0QFO0Ukbu2GrlTe3wjBunTwlsrCT0SLBzuj6cRoIIG9LRG1sjVf2J oi0isgXUlW0YQY0iBeo/Vj2yaxUq6RiN2TdXEhFcjDuL2FlVquxtqaCbNBT55MotyVXUf28Y U2ERbLnpBsaySzjEnNEyzA/bT6qvI/1nwdmh2KdKXZzrWbZed1ryBjE49zcWPhR0SYYSyljk zXXA1exPtaz8dWTjZfDvfiyV2S6WZJLaynk0ZuAtDen5W1tGRCzgui/msf7HggizS/7y95qW D3UoxnmZ4nr0722MeZmfklzGF/x8NF6G4F7kosonp4cw3kahpOP/XoGi2j/K9tb2bitJEYKE HQP3NifqFzhx0tLKm2PgYT0SiPZisBoYt3/ZmINxgo86dpLAeGa9u9qhyxw93O8pASZWvN9m zYB1bN64XoThacSswoozzmBKqgVGVhEMCfskRWR8t34q79YMjX8OYOs3VZzyIjyRIqJpRtRD SqoEn9DNSp578EldUnJzGW28IbvPt/ZcdMUsBSQ1RbGlelcbpwrxbIRnSQyH2X7sDU+zvIjy wR01MSzuIGBbX5m/Ke4HgJwLjrxdt8e8THrjL9Dk4CRxY/8Vo55FGAzVYDzBemtDCpUsP3mM wiUFzhpkU2gQe+FPzGCvXw6+mrIF4G3OnqXIngA0NgkQwOScUVbiQZSRz46m58lCiigw9Hne 0pioDVN9hj/sBQfgvlwOUzHW3zE7Bytdi9ySJWbK09O6Rpe4k7OLcGExudjRmdA+ZmwsAGGK mqafhlFS2YTVSRoHnjFOb+jrZnF+umcXK+lKufWJK+JoqpYXuuJwpSm1s1n+SyNP4OBJCsqC fpzwUdFUX1jfqaR0zwSVywakT7MZM+HtV+9/CNwtMW27PXsXkrm+4KOD7JYNdgn9QqxhO+PM OuZhSAxLjg9tNtEzHvBzv4E114Xij1yXyGqFaUcuCXNSqPJh6IRCAQUKmtyOMZO86Mgz1xVI 8eI77G9nrV8j/MzFxJETQm4wJDvPJRWZTrlcgibVyPpfPycKDbGwt/6e/a5QLxU1qBPsgGo/ CycGAnlNyiCkD/gU1auN/tNhWeVJk872sn1fxBzBGzkVN+jZAe8NYo9tgcNmehupE3XYFVAZ CB7d1JRo7aQ6yJBn/g5HHZOu3NhJO/CgC2Z6ujENr4ctuZtCSlv0ecG8DI90bQfv0QmDLRl3 TDfqNJjuQTsm+2GzHx8WxpLqypXrJqMuVR+NK7Z8JhZRHuC+wgCpzb1aVxCt55uDdvhvLpVw 97EmffoKTtMxNnT+NMVG8neLM/v3GMJCRPyA3aUCQIESWTuLmTDnwlHl/rU8HSJr588o5yqm ZwUS7YdWkZnXv8dD01kGpQFLvIVFnsfq4XD2ZQq22frl0WEXMJer4zKXfKUAOzyJXCel7YRb h8Bx/XjJoQWN5Hn80Zld19xkZ+MHhbAG9dXrUgDJkc4rV5M/353UmAokxu/O0X0uCNVTqbyx UJ+gxA2eek38Tbw/1o7bkHHoic9ighU+52tgDycdiLwMLblWIhXDyTusE1iepj/QgtzcUizh Rk9bmaCHuoNyeA4Mzs322q+8dNVFPVRTLNJekoVzPCTPbAz1EhE7z+gzglB7PfEDp1rkE0rd 4StpjROwVEGDpZ9KKrOKa5O1lUViLiJu3ri7doKmFpEBXgQpVjOLTYPvF0UO7ImISux4+Eq7 haNzjJHcW5KTPEqp/N26ms3PPmGxC/7lbsfOga2LePVfMb78yDQ0NWFRF89zBZCrHN+pe0s8 /k+JnHIAlgoyKqNGh8JM8vbNAwTaNBdoXHXdCDIqu7NxJNpI623Ef3uRuKV8qNIkgSjBgljT OFupowRW5Kr1k/fN8LuKrUInA4s6ArcL1KAFP1VeRiPnWRPs4SlwZRwx4UYOiAFDDA3L3Cs/ riO7FxP4rLLTJIsb3wdRIdBKn8mRJjwhXtCp3oZRHq2yr5LkVLTqWak+mKLVH+nM5IgZe/IN 0o2WZfvoWl5qPDw0gOykN2WZGDiaYYz45mWs7pc+czBUqsLBfp8qxmOwdEAHi72CmKXQ9fne JH9Ntt+M9CrWiThCTndw3p2Tt+vboz1dvHa3VjkHdQN4tjH0D1xZ5DmSD1MREsv/6lG7aZ4L 2XverIDaAXz/0Q7Pq27ekKD18m2BnyqIn1QRuVeyuOzY/pWyTAtZ6m00iloQpY/xuixuUkDI fNCxgnZ3uqmbpJCXDLbH2wEPR3IoTslmmNhMOcr3+p5xwnH+VURKDGEcuV1ZXcM5ottQwrKf TMtUixjGxeVlu+hqka00qoX/jdBktocyuBDvHXk/9febD+qRK23uMDVvi4nPpAtp6x8N5CmI 9PT7cmP2GWHEN+L6kveDH3fdbISgNVbLSNGTeMdnGgkPZZDoo9d8Q8rUcx4IbVTCa4qr7Tsa Dx+DCdUwzVKMuHIlDEEnOq43KPX0xmKd5F3eic+i80X2PkjTntNPnYGo6uyS4jdl2mFU3UGZ gAJ4lFF4AsG0JR7fuXk/JbgRphRzTVbuLRxDjuNEYNnvQieKCnekR3jRfOtnvb8lxpV1+7p2 8IHVQRXDFgEgf5Rklo0Jbp3LagJo4OMtSWHPxCf3iql2K6tI19fztfRflvzAd/etGbyZSYb/ GUdWY5FzHyMXYRXiQdyb7wn4UldOI3zMFir/CQqns46etvwHdDu3VsuqmwKAjunA8YUQf8zq 0rZAXVsK9WirJGvU32zampAoduFrFNIjEhmMyi40IdRbcZX7WxVNNCqiS2auMquRcZD385vE pJKJc1w6S+V8ExsMp+MpXY7ofrqlm+f/Coz4g7S+Q== IronPort-Data: A9a23:lgsm7KL0kedwyGwKFE+RdpElxSXFcZb7ZxGr2PjKsXjdYENShTEBm DRMWTrXO/aKZmX0fY91Pt7j8khS78OGx9U3SwYd+CA2RRqmi+KVXIXDdh+Y0wC6d5CYEho/t 63yTvGacajYm1eF/k/F3oDJ9CU6j+fSLlbFILasEjhrQgN5QzsWhxtmmuoo6qZlmtHR7zml4 LsemOWBfgb/s9JIGjhMsf7a8ks05K6aVA4w5zTSW9gb5DcyqFFOVPrzFYnpR1PkT49dGPKNR uqr5NlVKUuEl/uFIorNfofTKiXmcJaKVeS9oiY+t5yZv/R3jndaPpDXmxYrQRw/Zz2hx7idw TjW3HC6YV9B0qbkwIzxX/TEes3X0GIvFLLveBCCXcKvI0LueVL18tgwUxgKOYRI2fRNAm8Nr dkZJ2VYBvyDr7reLLOTT/k1wNwkKNj3MYgfvHB50DyfCuwpKXzBa/yQtJkBhGt23ZgIRqq2i 8kxMVKDaDz7WSYXbw01No9rp7v9nn77YiFVo1KTpLMq7i7U1gMk2bzkNpzOcdyPRNlJtkyfu 2TN8n+/B00KctuFxlJp91r117CWxHOgAtN6+LuQ+9Fzm3qM5zQpAQAdTlijpr68tU+lcocKQ 6AT0nFz8fZpqxTDosPGdxaxpXrBuh8HR/JLAugi4UeMzLDV6kCXHAA5oiVpbcx/8tcxQS022 1SJmdLwGDEpt6eaIZ6AyluKhTmbIBk4czBbWSsNHSgX2drt49kWjx2aG76PD5WJptHyHDjxx RWDoy4/m6gfgKY3O0OTpgCvb9WE/cihc+Il2jg7SF5J+StXXuaYi2GA7EiCq+5HKJeFQ1KBu nkdhsXY6/oBZX1sqMBvaLtXdF1Kz6/bWNE5vbKIN8NwnwlBA1b5IehtDMhWfS+FyPosdz7ze 1P0sghM/pJVN3bCRfYoONnoVZhxkvO+TYqNuhXogjxmPsYZmOivoHEGWKJs9zuFfLUEz/xiY snznTiEUS1HU8yLMwZat89GjON1nX9mrY8ibZ3wyBCqmaKZYG+JRLwFNlqXc+1x4bufqx29z jqsH5bi9vmra8WnOnO/2ddKdTgidCFrba0aXuQNJ4Zv1CI8STl5U5c8ANoJJ+RYokiivryZo yHnBh4IlQGXaL+uAVziV02PoYjHBf5XxU/X9wR2Vbpx8ylyOdSc/+0EeoEpfLIq0uVmwLQmB 7MGYsiMSLAHADjO5z1XP9G3oZ1AZSabo1uEHxOkRzwjIL9mZQjCoeH/ciXVqSIhMyuQtOkFm YOG6D/1e5Q5elldPJ7kU873l1KVlloBqd12RHrNc4Vyel2z0Y1EKB7Rr/4QIuMNI0792wrA6 RSyBE9AqMKQvYQw+9jtroKHprePDOFRMBd7HW7azLDuLgjc3DOp7rFhWdayXwL2dT3L6oT7Q ssN1ND6EvkMvGgSgrpGC7wxkJ4PvYr+lYFV3iFPPSvtbW3yLphCP3Pf/81ElpMV949joQHsB 36+oIhLC46oZvHgPkUafjc+T+K50voRpDnewNI1LGj+5w515LC3alpTDTbdlB1iKKZJD619z dcDoMI27ymNuiguOPuCjQFW8D2oBV4EWKMFqJobIdHKjiwG91J8WqHfWxTGuMy3V9ZxM0cRM mC1gojGjO9i3UbsSSc4OkXM+ut/vq4wni524mUMHHmzoeqdtMQLhEVQ1R8VUjVqyg521rMvG 2pzaGxwC6a83xZpo8lhQGr2C1xNKyOb82Os01A5qmn9Shi5ZH3sN0w4A/6Gp2oCwlJffx9a3 bCW83nkWjDUZ/PM3jM+dEpmiv77R/lzy1Hyo9+mFMG7AJUKWzrprauwb24uqRG8I8cOqGDYh OttpsBcVLbaMHMOnqgFFIWq77QcZxSaLmhkQ/s63qcoH3nZSQ6iywq1NEG9VcNcFcPkqXbiJ ZRVGftOcBCi2AKljDMRX/cMKoApus8Z3oMJf7ezKFMWt7eakCFSj6vR0SrDn04ufcRllJcsC 4HWdg/aKFequ1lvpzbvovVHa02CWvtVQC3n3euwzvcFKIJbjsFobnMJ8+WVu1e7DVJZ2iy67 SL5Wr/u7u19yI5TsZPmPYddCi6Vd97iduS63zqiktZJbNn/PtfqsSkLoHnjZzZpG7wbXtBnm YuwrdSs/kXkvak3YU/diZKuB6lE3uTsfet1Y+bcDmhWojuGY+DouyA8wmGfLYdbtf9g/eyle leIU9SxftsrRNtt/n1ZRCxAGRI7Ca6sTKPfiQ6ijvaLUD4x7BfmKY65yHrXcm1rTC8EFJngA AvSufz1xNR5rpxJNSAUFcNdHJ50D1/ya5QIL+Srm2GjMVCppVeetp/Jtxkqs2jLA0bZNvfK2 8vOQxymeSmivK3N8spijLVzmR8qF1d4v/g7exMM2txxig3iNlU8E8YmDcwkBK1XwwvI77OpV AGVOSFmQW/4UC9feBrx3MX7U03NTqYSM9P+PXoy81nSdy6yA5iaDaB88jt7pU17YSbn0PrtP OR2Fqcc5fRt6soBqScvCv2HbSNPw+ODgGoP/VHhnsfyBRcHHLhM02ZudOaIfTKSCNnDzS0nO kBsLV2ogmniIaIyLSqkU3RSBRcSsSipymk4KyCVz74zfq2FmfZYxqSX1/7bi9U+gQdjGFLKb WvwQ3qR7muW3H0KpKZvvMgm6UOx5TRnAeDiRJLeqcYuc21cJ4jp0w7uXcbCcS36xDNiLg== IronPort-HdrOrdr: A9a23:PmOHLawXpm84g5ouCeQcKrPwEb1zdoMgy1knxilNoH1uA6+lfq WV9sjzuiWbtN98YhwdcLO7WJVoI0m8yXcd2+B4VotKNzOIhILHFu1fxLqn6wKlMSzz/OxQ2M 5bAspDIey1K0N1yeLz4AzQKadF/DBrytHMudvj X-Talos-CUID: =?us-ascii?q?9a23=3ATDENlWuKaz4VRWahprIuMH8h6IsvW2Ts4SmPenO?= =?us-ascii?q?8ADZKWoeWRxzI3aJrxp8=3D?= X-Talos-MUID: =?us-ascii?q?9a23=3AcWlRzA4mMFSHEqFmL0V8xA5BxoxlzL21L18sya8?= =?us-ascii?q?PpsKfNjR3fDKijS+eF9o=3D?= X-IronPort-Anti-Spam-Filtered: true X-URL-LookUp-ScanningError: 1 X-IronPort-AV: E=Sophos;i="6.12,205,1728943200"; d="scan'208,217";a="197118329" X-MGA-submission: =?us-ascii?q?MDE6LGwFfSLc8WGNudKMSup+rCrywyAK6+FwJN?= =?us-ascii?q?WYmyge1MMf5ZlCNpf7a/sOWjMWGgadnSUyInyCvc/Bb8NyKVDwu0eHLe?= =?us-ascii?q?/f1tavUZ2CCaCHMlnNGgfcAKq4Mm6P5EaUU9Uy7mdQtoxy7hsMf3B8Bg?= =?us-ascii?q?XqDs4fVIlwvsUocWiIOcohMw=3D=3D?= Received: from mx1.polytechnique.org ([129.104.30.34]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Dec 2024 15:44:10 +0100 Received: from TM.local (unknown [82.66.240.41]) (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 58E9F564837; Tue, 3 Dec 2024 15:44:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=polytechnique.org; s=svoboda; t=1733237049; bh=GzI9cEsVUSeCWERtQjPXW8bhhospl6MoC+Y4WeegoL4=; h=From:To:Subject:Date:Message-ID; b=WxXL0huBqdKjIkbIKnKfZzAzvp4m7Xh1ZWpW7QFuiIMWNmW4W9MW6cR3RYKdW+WOB GADwsRyQUKyR2DBsv6WcBxn6pKHw+/FzOQ606xMnHCPg70pkDGITR3UAO8JZbRNE/9 0fR52Ul5VL7qYKgXZkOADW3JX5m1mCVraENbQZZg= From: Alan Schmitt To: "lwn" , caml-list@inria.fr Date: Tue, 03 Dec 2024 15:44:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-=-=" X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Tue Dec 3 15:44:10 2024 +0100 (CET)) X-Spam-Flag: Unsure, tests=bogofilter, spamicity=0.499841, queueID=D47CF564839 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: 19226 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 November 26 to December 03, 2024. 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 Good example of handwritten Lexer + Recursive Descent Parser? Boulder Dash in OCaml Js_of_ocaml 5.9.0 Liquidsoap 2.3.0 Bytesrw 0.1.0 =E2=80=93 Composable byte stream readers and writers dream-html and pure-html 3.5.2 Second beta release of OCaml 5.3.0 New release of Monolith Jsont 0.1.0 =E2=80=93 Declarative JSON data manipulation for OCaml Tiny educational concurrent I/O and promises library Eliom 11.1: Towards Web Assembly support Areas and Adversaries MariaDB 1.2.0 Proposed Package Archiving Policy for the opam Repository capnp-rpc 2.0 Other OCaml News Old CWN Good example of handwritten Lexer + Recursive Descent Parser? =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=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: Axel Baudot asked =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80 I am looking for an idiomatic implementation of a Lexer + Recursive Descent Parser not making use of ocamllex, ocamlyacc or menhir. The kind you would write during the first chapters of Crafting Interpreters [0][1] in OCaml. This Markdown parser [2] by @dbuenzli is a great example of what I am looking for. I'd be happy if you can recommend similar resources. There are many OCaml repos for Lox interpreters but it's hard to assess quality. And the readme often says "I am doing this to learn OCaml", which doesn't inspire confidence. As a broader note, it would be nice to have (community vetted) OCaml translations of well-known learning material using mainstream languages. But I'll raise the topic in another thread later. Thanks in advance. =E2=80=A2 [0] =E2=80=A2 [1] =E2=80=A2 [2] Mikhail replied =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 You might be interested in the book [Compiling to Assembly from Scratch]. There is a [port to OCaml]. It suggests the use of [parser combinators]. Parser combinators is the same manual recursive descent method, but in a functional way. You can either use [an existing library] or you [can write your own]. [Compiling to Assembly from Scratch] [port to OCaml] [parser combinators] [an existing library] [can write your own] Anton Bachin also replied =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 odoc's parser is half of what you're asking for. It uses ocamllex for the lexical scan, because it's very simple and convenient to do it that way, but the syntax is then analyzed by a hand-written [recursive descent parser], in large part because /that's/ easier for the doc language. An example of a non-ocamllex and non-ocamlyacc parser is Markup.ml ([tokenizer], [parser]). But this isn't a traditional recursive descent parser. Rather, it's a pretty huge hand-written state machine in continuation-passing style, almost completely implementing the corresponding huge state machine specified in HTML5. But it's the kind of code that fits well the topics of an impure FP class, especially since it has mutable cells for its continuations, that it uses to mimic effects. [recursive descent parser] [tokenizer] [parser] Boulder Dash in OCaml =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 Archive: Continuing this thread, Andreas Rossberg announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Couldn=E2=80=99t let it rest, so I=E2=80=99m (already) announcing version= 2 of it =E2=80=94 now a much improved, practically feature-complete reimplementation of both Boulder Dash 1 & 2. Version 2 was an excuse for me to mess around with the OCaml bindings to popular graphics engines, and as a result, it now comes with 3 backends to choose from: 1. the homely bare OCaml Graphics library (), 2. the TSDL binding to the SDL2 API (), 3. the binding to the Raylib engine (). The list is in order of increasingly better user experience, for the price of a potentially harder build experience. In theory, all versions should run on Windows, Mac, and Linux, though I was too lazy to test all combinations, and I (or my opam) had trouble installing some of the dependencies on some of the systems. Features: =E2=80=A2 Faithful original physics, graphics, animations, sound, and mus= ic =E2=80=A2 Authentic scrolling mechanics combined with dynamic resizing =E2=80=A2 All 40 levels and 5 difficulties of Boulder Dash 1 & 2 =E2=80=A2 Pause-and-go mode for relaxed playing Relative to the previous release, version 2 adds the following niceties: =E2=80=A2 Support for SDL and Raylib engines, which allow all of the foll= owing =E2=80=A2 Original sound effects and music =E2=80=A2 Original level color schemes =E2=80=A2 Full screen mode =E2=80=A2 Faster graphics =E2=80=A2 Dynamic graphics scaling adjustment =E2=80=A2 Gamepad/joystick support as well as more precise keyboard contr= ols =E2=80=A2 Boulder Dash 2 levels and decoder Almost looks like a real game now. One from the 80s anyways. :) Js_of_ocaml 5.9.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 Archive: Hhugo 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 I=E2=80=99m pleased to announce the release of js_of_ocaml 5.9.0. It shou= ld soon be available in opam. Js_of_ocaml is a compiler from OCaml bytecode to JavaScript. It makes it possible to run pure OCaml programs in JavaScript environment like browsers and Node.js. Most significant changes: =E2=80=A2 Support for OCaml 5.3 =E2=80=A2 Speedup sourcemap generation and improve sourcemap accuracy. =E2=80=A2 Prepare the merge of the wasm_of_ocaml fork back into the js_of_ocaml repo. =E2=80=A2 JS backtraces are really expansive. They now need to be explici= tly requested with `OCAMLRUNPARM=3Db=3D1'. This speeds up programs linked with libraries enabling backtraces programmatically using `Printexc.record_backtrace true'. See the [Changelog ] for other changes. [Changelog ] Liquidsoap 2.3.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 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 We are stoked to announce the `2.3.0' release of liquidsoap, a general-purpose scripting language written in OCaml with specialized operators to build media streams. The release is available on github: During this release cycle, we have rewritten huge chunk of the application's internal, including a new media streaming abstraction and clock system. As an OCaml application, liquidsoap's scope and complexity has greatly expanded in the next years. Some of the most challenging areas for us at this point are memory usage (and, incidentally, CPU usage). Although OCaml's garbage collection is a very powerful tool, in the context of very short lived streaming cycles (typically `0.02s') with potentially quite large memory allocations (typically video images), controlling the timing of memory allocations and release is becoming more and more critical. We are also aware of the work done by Jane St on adding a `local' call stack. This could be an avenue to explore as well but: 1. Some of our content has to be stored in the long-term heap 2. We want to work with an official OCaml compiler for obvious long-term maintenance concerns. Nonetheless, we are thrilled to be part of a community whose array of tools (building, packaging, debugging, etc) and libraries has expanded so well along with a vibrant compiler development team. In the future, we wish to explore more of the new OCaml concurrency features. This might require that we revisit the way we handle short-term memory first. Bytesrw 0.1.0 =E2=80=93 Composable byte stream readers and writers =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =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: Daniel B=C3=BCnzli 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 It's my pleasure to announce the first release of the `bytesrw' library: Bytesrw extends the OCaml `Bytes' module with composable, memory efficient, byte stream readers and writers compatible with effect-based concurrency. Except for byte slice life-times, these abstractions intentionally separate away ressource management and the specifics of reading and writing bytes. Bytesrw distributed under the ISC license. It has no dependencies. Optional support for compressed and hashed bytes depend, at your wish, on the C [`zlib'], [`libzstd'], [`blake3'], [`libmd'], [`xxhash'] and libraries. The only reason I was longing for OCaml algebraic effects was so that I could avoid using them: when you write codecs on byte streams it should not be a concern where your bytes are coming from or headed to. The `bytesrw' library provides structures to abstract this. Additionally it establishes a buffer ownership discipline that enables byte streams to (de)compose while remaining memory efficient. I do not expect the library to change much and it has been used. But it's new and practice may call for adjustments. Do not hesitate to get in touch if you run into problems or see obvious defects or improvements. I do expect the library will add more convenience (e.g. for processing lines and UTF) and more optional stream formats over time. =E2=80=A2 Homepage: =E2=80=A2 Docs: or `odig doc bytesrw' =E2=80=A2 Install: `opam install bytesrw conf-zlib conf-zstd conf-libblak= e3 conf-libmd conf-xxhash' ([opam PR]) This first release was made possible thanks to a grant from the [OCaml Software Foundation]. I also thank my [donors] for their support. [`zlib'] [`libzstd'] [`blake3'] [`libmd'] [`xxhash'] [opam PR] [OCaml Software Foundation] [donors] dream-html and pure-html 3.5.2 =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 Archive: Yawar Amin 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 [ANN] dream-html 3.7.0 Happy to announce the addition of a helper module for typed form decoding functionality. See the docs here: An example: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 type user =3D { name : string; age : int option } =E2=94=82=20 =E2=94=82 open Dream_html.Form =E2=94=82=20 =E2=94=82 let user_form =3D =E2=94=82 let+ name =3D required string "name" =E2=94=82 and+ age =3D optional int "age" in =E2=94=82 { name; age } =E2=94=82=20 =E2=94=82 let dream_form =3D ["age", "42"; "name", "Bob"] =E2=94=82 let user_result =3D validate user_form dream_form =E2=94=82 (* =3D> Ok { name =3D "Bob"; age =3D Some 42 } *) =E2=94=82=20 =E2=94=82 let error_result =3D validate user_form ["age", "none"] =E2=94=82 (* =3D> Error [("age", "error.expected.int"); ("name", "error.r= equired")] *) =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Astute readers may observe that this provides some convenience functionality beyond what Dream itself offers; to validate the above form and get a _complete_ set of field validation errors using only Dream you would do something like: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 let user_result =3D match dream_form with =E2=94=82 | ["age", age; "name", name] -> =E2=94=82 (match int_of_string age with =E2=94=82 | age -> Ok { name; age =3D Some age } =E2=94=82 | exception Failure _ -> Error ["age", "error.expected.int"= ]) =E2=94=82 | ["name", name] -> Ok { name; age =3D None } =E2=94=82 | ["age", age] -> =E2=94=82 (match int_of_string age with =E2=94=82 | age -> Error ["name", "error.required"] =E2=94=82 | exception Failure _ -> Error ["age", "error.expected.int"= ; "name", "error.required"]) =E2=94=82 | _ -> Error ["name", "error.required"] =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 And this is a form with only two fields. You can imagine how convoluted the logic would be for more complex forms. Of course, you might just decide to use `List.assoc_opt' and build up the validation errors, but even that can get tricky. So if you are making heavy use of HTML forms, a helper module that takes care of all these validation details can be very useful. Enjoy! Second beta release of OCaml 5.3.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=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90 Archive: octachron 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 One month after the release of the first beta for OCaml 5.3.0, we are releasing a second and hopefully last beta release for OCaml 5.3.0 . The most notable changes for this second beta are probably a handful of type system bugfixes. In particular, those fixes revert a change of behaviour in the first beta when pattern matching GADTs with non-injective type parameters. We also have a C++ header compatibility fix and the restoration of some configuration variable in Makefiles for the sake of backward compatibility. Overall, the release is converging and we are expecting to have a first release candidate around the middle of December. The progresses on stabilising the ecosystem are tracked on the [opam readiness for 5.3.0 meta-issue]. Meanwhile, the second beta release of OCaml 5.3.0 is here to help you update your software and libraries ahead of the release (see below for the installation instructions). The full release is expected before the end of December. If you find any bugs, please report them on [OCaml's issue tracker]. If you are interested in full list of features and bug fixes of the new OCaml version, the updated change log for OCaml 5.3.0 is available [on GitHub]. Happy hacking, Florian Angeletti for the OCaml team. [opam readiness for 5.3.0 meta-issue] [OCaml's issue tracker] [on GitHub] Installation Instructions =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95= =8C=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 base compiler can be installed as an opam switch with the following commands on opam 2.1 and later: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 opam update =E2=94=82 opam switch create 5.3.0~beta2 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 The source code for the beta is also available at these addresses: =E2=80=A2 [GitHub] =E2=80=A2 [OCaml archives at Inria] [GitHub] [OCaml archives at Inria] =E2=97=8A Fine-Tuned Compiler Configuration If you want to tweak the configuration of the compiler, you can switch to the option variant with: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 opam update =E2=94=82 opam switch create ocaml-variants.5.3.0~beta2+opt= ions =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 where `option_list' is a space separated list of `ocaml-option-*' packages. For instance, for a flambda and no-flat-float-array switch: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 opam switch create 5.3.0~beta2+flambda+nffa ocaml-variants.5.3.= 0~beta2+options ocaml-option-flambda ocaml-option-no-flat-float-array =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 All available options can be listed with `opam search ocaml-option'. Changes Since The First Beta =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95= =8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=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 Type system fixes =E2=80=A2 [#13501]: Regression on mutually recursive types caused by [#12= 180]. Resuscitate Typedecl.update_type. (Jacques Garrigue and Takafumi Saikawa, review by Florian Angeletti, Richard Eisenberg and Gabriel Scherer) =E2=80=A2 [#13495], [#13514]: Fix typechecker crash while typing objects (Jacques Garrigue, report by Nicol=C3=A1s Ojeda B=C3=A4r, review by Nic= olas Ojeda B=C3=A4r, Gabriel Scherer, Stephen Dolan, Florian Angeletti) =E2=80=A2 [#13598]: Falsely triggered warning 56 [unreachable-case] This = was caused by unproper protection of the retyping function. (Jacques Garrigue, report by T=C3=B5ivo Leedj=C3=A4rv, review by Florian Angelet= ti) [#13501] [#12180] [#13495] [#13514] [#13598] =E2=97=8A Configuration fixes =E2=80=A2 (*breaking change*) [#12578], [#12589], [#13322], +[#13519]: Use configured CFLAGS and CPPFLAGS /only/ during the build of the compiler itself. Do not use them when compiling third-party C sources through the compiler. Flags for compiling third-party C sources can still be specified at configure time in the COMPILER_{BYTECODE,NATIVE}_{CFLAGS,CPPFLAGS} configuration variables. (S=C3=A9bastien Hinderer, report by William Hu, review by David Allsopp) [#12578] [#12589] [#13322] [#13519] =E2=97=8A C++ header compatibility =E2=80=A2 [#13541], [#13591]: Fix headers for C++ inclusion. (Antonin D= =C3=A9cimo, review by Nick Barnes, report by Kate Deplaix) [#13541] [#13591] =E2=97=8A Compiler library bug fix =E2=80=A2 [#13603], [#13604]: fix source printing in the presence of the escaped raw identifier `\#mod'. (Florian Angeletti, report by Chris Casinghino, review by Gabriel Scherer) [#13603] [#13604] New release of Monolith =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=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: Fran=C3=A7ois Pottier 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 I am pleased to announce a new release of [Monolith], a library that helps perform strong automated testing of OCaml libraries. =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 opam update =E2=94=82 opam install monolith.20241126 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 The changes are as follows: =E2=80=A2 The documentation of the specification combinators has been re-organized in sections and subsections. Finding the desired combinator should now be easier. =E2=80=A2 The new combinator `naive_array' offers limited support for arr= ays. =E2=80=A2 The new combinator `naive_seq' offers limited support for seque= nces (that is, for the type constructor `Seq.t'). =E2=80=A2 The new combinator `pair' is a synonym for `( *** )'. =E2=80=A2 The new combinator `triple' offers support for triples. =E2=80=A2 The new combinator `either' offers support for the type constru= ctor `Either.t'. =E2=80=A2 The new combinators `iter', `foldr', `foldl', `iteri', `foldri', `foldli' offer support for iteration functions. =E2=80=A2 An unintentional and undocumented limitation has been fixed: so= far, uses of the combinator `map_into' would work only at the root of the specification or in the right-hand side of an arrow `^>'. It should now be possible to use `map_into' under other combinators that expect a deconstructible specification, such as `^!>' (in the right-hand side), `( *** )', `option', `result', `list', etc. This improvement affects not only `map_into', but also a number of other combinators that are defined in terms of `map_into'. =E2=80=A2 Monolith now requires OCaml 4.12 or later. =E2=80=A2 In `Makefile.monolith', =E2=81=83 the default switch is changed from 4.11.1 to 4.14.2; this can= be overridden by defining `SWITCH'; =E2=81=83 `make test' automatically disables the MacOS crash reporter; =E2=81=83 the use of `ulimit -s' is abandoned. [Monolith] Jsont 0.1.0 =E2=80=93 Declarative JSON data manipulation for OCaml =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 Archive: Daniel B=C3=BCnzli 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 It's my pleasure to announce the first release of the jsont libary: Jsont is an OCaml library for declarative JSON data manipulation. It provides: =E2=80=A2 Combinators for describing JSON data using the OCaml values of your choice. The descriptions can be used by generic functions to decode, encode, query and update JSON data without having to construct a generic JSON representation. =E2=80=A2 A JSON codec with optional text location tracking and layout preservation. The codec is compatible with effect-based concurrency. The descriptions are independent from the codec and can be used by third-party processors or codecs. Jsont is distributed under the ISC license. It has no dependencies. The codec is optional and depends on the [`bytesrw'] library. The JavaScript support is optional and depends on the [`brr'] library. The library has been used in practice but it's new so a few adjustments may be needed and more convenience combinators added. The library also enables quite a few things that I did not have the time to explore like schema description generation from descriptions, quasi-streaming JSON transformations, description generation from dynamic type representations, etc. Lots of this can be done outside the core library, do not hesitate to get in touch if you use the library and find interesting applications or pesking limitations. =E2=80=A2 Homepage: =E2=80=A2 Docs: (or `odig doc jsont') =E2=80=A2 Install: `opam install jsont bytesrw' This first release was made possible thanks to a grant from the [OCaml Software Foundation]. I also thank my [donors] for their support. Best, Daniel P.S. I think that the technique used by the library, which I dubbed /finally tagged/ is interesting in itself. You can read a paper about it [here] along with a smaller, self-contained, implementation of what the library does. [`bytesrw'] [`brr'] [OCaml Software Foundation] [donors] [here] Tiny educational concurrent I/O and promises library =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=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: Mikhail 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 I like [Lwt]. It's a fantastic library, but how does it work? I spent a few days studying its source code. Finally, inspired by the implementation of [Lwt] and [the CS3110 chapter, 8.7. Promises]. I wrote a maximally stupid [*tiny-async-lib*] library. Maybe you may be interested in this naive implementation. [Lwt] [the CS3110 chapter, 8.7. Promises] [*tiny-async-lib*] Examples of use =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 let () =3D=20 =E2=94=82 Engine.run main begin =E2=94=82 let* () =3D Io.(write_all stdout) "Hi! What's your name? " = in =E2=94=82 let* name =3D Io.(read_line stdin) in =E2=94=82 Io.(write_all stdout) ("Hello, " ^ name ^ "!\n") =E2=94=82 end =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 let read_and_print_file filename =3D=20 =E2=94=82 Io.(read_file filename >>=3D write_all stdout) =E2=94=82=20 =E2=94=82 let _ =3D =E2=94=82 Engine.run begin =E2=94=82 let filenames =3D [ (* ... *) ] in=20=20 =E2=94=82=20 =E2=94=82 filenames =E2=94=82 |> List.map read_and_print_file =E2=94=82 |> Promise.join =E2=94=82 end =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Implementation details =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=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 first key abstraction of the whole library is, of course, Promise. [Promise] is an abstraction for synchronizing program execution in concurrent evaluations. In simple terms, it's an abstraction over callbacks. Promises allows us to build (monadic) sequence evaluations inside of non-sequence evaluations. =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 (* promise.ml *) =E2=94=82=20 =E2=94=82 type 'a t =3D { mutable state: 'a state }=20=20 =E2=94=82=20 =E2=94=82 and 'a state =3D=20 =E2=94=82 | Fulfilled of 'a=20 =E2=94=82 | Rejected of exn =E2=94=82 | Pending of 'a callback list=20 =E2=94=82=20 =E2=94=82 and 'a callback =3D 'a state -> unit=20 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Promises are represented as a mutable record with three possible states: fulfilled (contains a value), rejected (contains an exception), and pending (contains callbacks). Callbacks are functions that are called when a promise is resolved. So when we `bind', if the promise is in pending state, we add a callback that calls the following monadic sequence when the promise is resolved. =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 (* io.ml *) =E2=94=82=20 =E2=94=82 let sleep delay =3D =E2=94=82 let p, r =3D Promise.make () in =E2=94=82=20 =E2=94=82 Engine.(on_timer instance) delay (fun handler -> =E2=94=82 Engine.stop_handler handler; =E2=94=82 Promise.fulfill r ()); =E2=94=82=20 =E2=94=82 p =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 The second key abstraction is an [asynchronous I/O] engine that polls I/O events and dispatches them to handlers. Original Lwt has few engines (like based libev, select, poll), but I hardcoded a [select]()-based engine inspired by `Lwt_engine.select_based'. The typical async engine in internals has an event loop. At each iteration of the event loop, the engine polls for new events and calls handlers to handle them. =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 (* engine.ml *) =E2=94=82=20 =E2=94=82 let iter engine =3D =E2=94=82 (* ... *) =E2=94=82=20 =E2=94=82 let readable_fds, writable_fds, _ =3D =E2=94=82 Unix.select readable_fds writable_fds [] timeout =E2=94=82 in =E2=94=82=20 =E2=94=82 engine.sleepers <- restart_sleepers now engine.sleepers; =E2=94=82=20 =E2=94=82 invoke_io_handlers engine.wait_readable readable_fds; =E2=94=82 invoke_io_handlers engine.wait_writable writable_fds =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 How to execute I/O promise? It's not a big deal. =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 (* engine.ml *) =E2=94=82=20 =E2=94=82 let rec run promise =3D =E2=94=82 match Promise.state promise with =E2=94=82 | Fulfilled value -> value =E2=94=82 | Rejected exc -> raise exc =E2=94=82 | Pending _ -> =E2=94=82 iter instance; =E2=94=82 run promise =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 We just need to loop the event loop until the promis is resolved. It's just a toy! I'm not an expert in such things, so the library is very naive and tries to mimic Lwt. But I think it's a good demonstration. Repository Thank you for your attention! [Promise] [asynchronous I/O] Eliom 11.1: Towards Web Assembly support =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=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: Vincent Balat 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 Eliom 11.1 has been released recently. This minor release brings compatibility with Web Assembly and the upcoming version of js_of_ocaml. Ocsigen Toolkit and Ocsigen Start have been updated as well. Stay tuned for further announcements concerning client-server Web and mobile apps in Ocaml with Web Assembly! Links: =E2=80=A2 [Ocsigen] =E2=80=A2 [Eliom] =E2=80=A2 [Documentation] =E2=80=A2 [Github] [Ocsigen] [Eliom] [Documentation] [Github] Areas and Adversaries =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=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: Rapha=C3=ABl Proust 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 I figured people might be bored of [British pub names] by now so I did another thing: [a generator for titles of table-top role-playing games]. =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 $ opam install areas-and-adversaries =E2=94=82 ... =E2=94=82 $ areas-and-adversaries =E2=94=82 Woods & Wizards =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 The code is on Gitlab: It was a good excuse to experiment with non-dune build systems (to scope things out). I went for a plain Makefile in the end which works well. I also wanted to figure out a better way to embed data in an executable. I ended up wondering about moving as much of the processing as possible into the build phase. What I ended up with is a small program which prints a compilation unit (`.ml') which has mostly array literals. Still have some open questions on that, any input welcome: =E2=80=A2 Should I have used meta-ocaml to print the code? The `data/munc= h.ml' would probably be more readable, but the build probably less. =E2=80=A2 How could I generate this kind of processed-data code for data-structures which don't have a literal (maps, sets, hash tables, etc.)? How can I minimise the initialisation cost of the program for such situations? [British pub names] [a generator for titles of table-top role-playing games] MariaDB 1.2.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 Archive: Petter A. Urkedal 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 I'm please to announce a new release of the [mariadb] package, which provides client bindings for MariaDB and MySQL. See the full release notes below. This is also to announce that I have taken over maintenance of the project. Currently I am the sole maintainer (and I usually use PostgreSQL for my own deployments), so if someone has the time en interest to contribute, let me know. The main focus from my side is to keep the project up to date and stable, rather than making major changes. Release notes: =E2=80=A2 Added `Stmt.start_txn' (#59 by Corentin Leruth). =E2=80=A2 Added `Res.insert_id' as binding for `mysql_stmt_insert_id' (#5= 8 by Corentin Leruth). =E2=80=A2 Updated to support recent OCaml versions (#45 by @kit-ty-kate). =E2=80=A2 Fixed too-early retrieval of statement metadata (#41 by Albert Peschar). =E2=80=A2 Fixed decoding bug for the integer type (#54 by Raman Varabets, tested by #61 by Corentin Leruth). =E2=80=A2 Fixed a memory leaks related to result metadata (#39 by Albert Peschar). =E2=80=A2 The build system is now dune and dune-configurator (#52 by Pett= er A. Urkedal) and some of the examples have been converted to a test suite (#60 by Petter A. Urkedal). =E2=80=A2 The project has been transferred to ocaml-community with Petter= A. Urkedal as the new maintainer. [mariadb] Proposed Package Archiving Policy for the opam Repository =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=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 please to announce the proposed package archiving policy in the name of the opam-repository maintainers. Context =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C The opam repository differs from nearly all other programming-language-centric package repositories in that it is manually curated by volunteer maintainers and protected by a robust continuous integration system that (generally) ensures published packages work as expected across a [large matrix of supported platforms]. Over the past few years the repository has kept growing steadily, when not accelerating, and this has started raising questions about the size, weight and sustainability of the repository and its processes. Last year, [Hannes Mehnert] requested comments on a [proposed initiative] to improve the sustainability and quality of the opam package repository on the long term. [large matrix of supported platforms] [Hannes Mehnert] [proposed initiative] Problem =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C The problem, in a nutshell, is that the `opam-repository' will keep steadily growing, using an increasing and substantial amount of space and inodes. Every opam user needs to invest a large amount of computational resources for the solver, every time they want to install or update a package. Additionally, a large amount of computational resources are spent in the continuous integration process and yet a lot of the packages have become stale or uninstallable. Solution =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C [After much deliberation], the discussion converged on a solution: introduce a package archiving policy and supporting processes, to periodically identify and prune unmaintained and broken packages from the repository. This will improve the performance of the opam solvers, of the opam-repo CI, and most importantly improve the quality of the package repository, while keeping a sort of immutability of the repository content and preserving the usability of historical packages for the users that want or need them. The opam repository maintainers propose a [policy]. The currently empty [repository archive] has been created, waiting for packages to be moved. [After much deliberation] [policy] [repository archive] Call to action =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C If you maintain packages in the opam-repository, you can help by defining your maintanence intent: add a new field `x-maintenance-intent' to your opam file(s) (the most recent release of your package is sufficient - please also put this field in your git repository so it will be part of future releases). The value is defined in [the policy]. [the policy] Roadmap =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C All announcements will be on discuss.ocaml.org with the opam-repository tag. If you like to follow these announcements, keep your eyes at [the opam-repository tag]. =E2=80=A2 December 1st 2024: announcement of this proposal =E2=80=A2 December 15th 2024: announcement of the packages affected by Ph= ase 1 (uninstallable packages ("available: false", "flags: avoid-version" or "deprecated", "opam admin check =E2=80=93installable", does not comp= ile =E2=80=93 opam health check ) =E2=80=A2 January 1st 2025: Phase 1 cutting point: packages are moved to opam-repository-archive =E2=80=A2 January 15th 2025: announcement of the packages affected by Pha= se 2 (OCaml lower bound 4.08) =E2=80=A2 February 1st 2025: Phase 2 cutting point: packages are moved to opam-repository-archive =E2=80=A2 February 15th 2025: initial spring cleaning, announcement of packages (based on maintenance-intent) =E2=80=A2 March 1st 2025: spring cleaning cutting point: packages are mov= ed to opam-repository-archive =E2=80=A2 Every quarter: repeat Phase 3 =E2=80=A2 Every year: reconsider Phase 2 with an increased OCaml lower bo= und We now invite members of the OCaml community who may not follow the ocaml-repository issues to review our plans and submit comments, questions, or suggestions. Thank you in advance for your support! [the opam-repository tag] References =E2=95=8C=E2=95=8C=E2=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 [Opam repository archive] =E2=80=A2 [Proposed policy] =E2=80=A2 [Plan of action] =E2=80=A2 [Issue and discussion] =E2=80=A2 [Previous announcement] [Opam repository archive] [Proposed policy] [Plan of action] [Issue and discussion] [Previous announcement] Acknowledgment =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C Thanks to the following individuals for valuable input and contributions to the planning process (sorry in case we forgot you): =E2=80=A2 Marcello Seri =E2=80=A2 Shon Feder =E2=80=A2 Thomas Gazagnaire =E2=80=A2 kit-ty-kate =E2=80=A2 Weng Shiwei =E7=BF=81=E5=A3=AB=E4=BC=9F =E2=80=A2 Marcus Rohrmoser =E2=80=A2 Reynir Bj=C3=B6rnsson =E2=80=A2 Stephen Sherratt =E2=80=A2 Simon Cruanes =E2=80=A2 Marek Kubica =E2=80=A2 Rapha=C3=ABl Proust =E2=80=A2 Romain Beauxis =E2=80=A2 Yawar Amin =E2=80=A2 Anil Madhavapeddy =E2=80=A2 Boning D. =E2=80=A2 Mathieu Barbin =E2=80=A2 Hannes Mehnert capnp-rpc 2.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 Archive: Thomas Leonard 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 I'm pleased to announce the release of [capnp-rpc 2.0], an OCaml implementation of the Cap'n Proto RPC specification. If you haven't used the library before, please see the [documentation and tutorial]. Cap'n Proto RPC aims to provide secure, efficient, typed communications between multiple parties. The main change in this version is the switch from Lwt to Eio for concurrency. The echo benchmark is about 40% faster than before. This isn't because Eio is actually that much faster than Lwt, but more because it has better profiling support so spotting problems was easier. See for an example: There is a `capnp-rpc-lwt' compatibility package that provides the old Lwt API using the new Eio version, allowing libraries using the old API to be used in applications using the new code, without having to update everything at once. To migrate to the new version (checking everything still works after each step): 1. First, update to capnp-rpc 1.2.4 (this ensures you are using the newer mirage-crypto API, to get that migration out of the way first). 2. Switch your application (that sets up the networking) to capnp-rpc-unix 2.0. 3. Migrate client and server code away from capnp-rpc-lwt when convenient. For more detailed instructions, see [the changelog]. Here's an example of the changes needed in the solver-service project: =E2=80=A2 [Update to capnp-rpc-unix 2.0] =E2=80=A2 [Remove Capnp_rpc_lwt] [capnp-rpc 2.0] [documentation and tutorial] [the changelog] [Update to capnp-rpc-unix 2.0] [Remove Capnp_rpc_lwt] 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 [Irmin on MirageOS: Introducing the Notafs File System] [the ocaml.org blog] [Irmin on MirageOS: Introducing the Notafs File System] 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 November 26 to Decemb= er 03, 2024.

Good example of handwritten Lexer + Recursive Descent Parser?<= /h2>

Archive: https://discuss.ocaml.org/t/good-e= xample-of-handwritten-lexer-recursive-descent-parser/15672/1

Axel Baudot asked

I am looking for an idiomatic implementation of a Lexer + Recursive Descent= Parser not making use of ocamllex, ocamlyacc or menhir. The kind you would= write during the first chapters of Crafting Interpreters [0][1] in OCaml.

This Markdown parser [2] by @dbuenzli is a great example of what I am looki= ng for. I'd be happy if you can recommend similar resources.

There are many OCaml repos for Lox interpreters but it's hard to assess qua= lity. And the readme often says "I am doing this to learn OCaml", which doe= sn't inspire confidence.

As a broader note, it would be nice to have (community vetted) OCaml transl= ations of well-known learning material using mainstream languages. But I'll= raise the topic in another thread later.

Thanks in advance.

Mikhail replied

You might be interested in the book Compiling to Assembly from Scratch. There is a port to OCaml. It suggests the use of parser c= ombinators.=20

Parser combinators is the same manual recursive descent method, but in a fu= nctional way. You can either use an existing library or you can write your own.

Anton Bachin also replied

odoc's parser is half of what you're asking for. It uses ocamllex for the l= exical scan, because it's very simple and convenient to do it that way, but the syntax is then analyzed by a hand-written recursive descent parser, in large part because that's easier for the doc language.

An example of a non-ocamllex and non-ocamlyacc parser is Markup.ml (tokenizer, parser). But this isn't a traditional recursive descent parser. Rather, it's a pretty huge ha= nd-written state machine in continuation-passing style, almost completely implementing the corresponding huge state machine specifi= ed in HTML5. But it's the kind of code that fits well the topics of an impure FP class, especially since it has mutable cells for its= continuations, that it uses to mimic effects.

Boulder Dash in OCaml

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2024-11/msg00023.html=

Continuing this thread, Andreas Rossberg announced

Couldn=E2=80=99t let it rest, so I=E2=80=99m (already) announcing version 2= of it =E2=80=94 now a much improved, practically feature-complete reimplementation of both Boulder Dash 1 & 2.

Version 2 was an excuse for me to mess around with the OCaml bindings to po= pular graphics engines, and as a result, it now comes with 3 backends to choose from:

  1. the homely bare OCaml Graphics library (https://github.com/ocaml/graphics),
  2. the TSDL binding to the SDL2 API (https://github.com/dbuenzli/tsdl),
  3. the binding to the Raylib engine (https://github.com/tjammer/raylib-ocaml).

The list is in order of increasingly better user experience, for the price = of a potentially harder build experience. In theory, all versions should run on Windows, Mac, and Linux, though I was too lazy to te= st all combinations, and I (or my opam) had trouble installing some of the dependencies on some of the systems.

Features:

  • Faithful original physics, graphics, animations, sound, and music
  • Authentic scrolling mechanics combined with dynamic resizing
  • All 40 levels and 5 difficulties of Boulder Dash 1 & 2
  • Pause-and-go mode for relaxed playing

Relative to the previous release, version 2 adds the following niceties:

  • Support for SDL and Raylib engines, which allow all of the following
  • Original sound effects and music
  • Original level color schemes
  • Full screen mode
  • Faster graphics
  • Dynamic graphics scaling adjustment
  • Gamepad/joystick support as well as more precise keyboard controls
  • Boulder Dash 2 levels and decoder

Almost looks like a real game now. One from the 80s anyways. :)

Js_of_ocaml 5.9.0

Archive: https://discuss.ocaml.org/t/ann-js-of-ocaml-5-9-0/15674/1

Hhugo announced

I=E2=80=99m pleased to announce the release of js_of_ocaml 5.9.0. It should= soon be available in opam.

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

Most significant changes:

  • Support for OCaml 5.3
  • Speedup sourcemap generation and improve sourcemap accuracy.
  • Prepare the merge of the wasm_of_ocaml fork back into the js_of_ocaml r= epo.
  • JS backtraces are really expansive. They now need to be explicitly requ= ested with OCAMLRUNPARM=3Db=3D1. This speeds up programs linke= d with libraries enabling backtraces programmatically using Printexc.= record_backtrace true.

See the Changelog for other changes.

Liquidsoap 2.3.0

Archive: https://discuss.ocaml.org/t/ann-liquidsoap-2-3-0/15677/1

Romain Beauxis announced

We are stoked to announce the 2.3.0 release of liquidsoap, a g= eneral-purpose scripting language written in OCaml with specialized operato= rs to build media streams.

The release is available on github: https://github.com/savonet/liquidsoap/releas= es/tag/v2.3.0

During this release cycle, we have rewritten huge chunk of the application'= s internal, including a new media streaming abstraction and clock system.

As an OCaml application, liquidsoap's scope and complexity has greatly expa= nded in the next years.

Some of the most challenging areas for us at this point are memory usage (a= nd, incidentally, CPU usage).

Although OCaml's garbage collection is a very powerful tool, in the context= of very short lived streaming cycles (typically 0.02s) with p= otentially quite large memory allocations (typically video images), control= ling the timing of memory allocations and release is becoming more and more= critical.

We are also aware of the work done by Jane St on adding a local call stack. This could be an avenue to explore as well but:

  1. Some of our content has to be stored in the long-term heap
  2. We want to work with an official OCaml compiler for obvious long-term m= aintenance concerns.

Nonetheless, we are thrilled to be part of a community whose array of tools= (building, packaging, debugging, etc) and libraries has expanded so well a= long with a vibrant compiler development team.

In the future, we wish to explore more of the new OCaml concurrency feature= s. This might require that we revisit the way we handle short-term memory f= irst.

Bytesrw 0.1.0 =E2=80=93 Composable byte stream readers and wri= ters

Archive: https://discuss.ocaml.org/t/ann-= bytesrw-0-1-0-composable-byte-stream-readers-and-writers/15696/1

Daniel B=C3=BCnzli announced

It's my pleasure to announce the first release of the bytesrw = library:

Bytesrw extends the OCaml Bytes module with composable, memory= efficient, byte stream readers and writers compatible with effect-based co= ncurrency.

Except for byte slice life-times, these abstractions intentionally separat= e away ressource management and the specifics of reading and writing bytes.

Bytesrw distributed under the ISC license. It has no dependencies.

Optional support for compressed and hashed bytes depend, at your wish, on = the C zlib, libzstd, bl= ake3, = libmd, xxhash a= nd libraries.

The only reason I was longing for OCaml algebraic effects was so that I cou= ld avoid using them: when you write codecs on byte streams it should not be= a concern where your bytes are coming from or headed to. The bytesrw= library provides structures to abstract this. Additionally it estab= lishes a buffer ownership discipline that enables byte streams to (de)compo= se while remaining memory efficient.

I do not expect the library to change much and it has been used. But it's n= ew and practice may call for adjustments. Do not hesitate to get in touch i= f you run into problems or see obvious defects or improvements. I do expect= the library will add more convenience (e.g. for processing lines and UTF) = and more optional stream formats over time.

This first release was made possible thanks to a grant from the OCaml Software Foundation. I also thank my donors for their support.

dream-html and pure-html 3.5.2

Archive: https://discuss.ocaml.org/t/ann-dream-html-pure-html-3-5-2/148= 08/5

Yawar Amin announced

[ANN] dream-html 3.7.0

Happy to announce the addition of a helper module for typed form decoding f= unctionality. See the docs here: https://yawaramin.github.io/= dream-html/dream-html/Dream_html/Form/index.html

An example: 

type user =3D { name : s=
tring; age : int option }

open Dream_html.Form

let user_form =3D
  let+ name =3D required string "name"
  and+ age =3D optional int "age" in
  { name; age }

let dream_form =3D ["age", "42"; "name", "Bob"]
let user_result =3D validate user_form dream_form
(* =3D> Ok { name =3D "Bob"; age =
=3D Some 42 } *)=


let error_result =3D validate user_form ["age", "none"<=
/span>]
(* =3D> Error [("age", "error.expe=
cted.int"); ("name", "error.required")] *)

Astute readers may observe that this provides some convenience functionalit= y beyond what Dream itself offers; to validate the above form and get a complete set of field validation errors using= only Dream you would do something like: 

let user_result =3D match dream_form with
  | ["age", age; "name", name] ->
    (match int_of=
_string age with
    | age -> =
Ok { name; age =3D Some age }
    | exception <=
span style=3D"color: #242521; background-color: #fcf7ef;">Failure _ =
-> Error ["age", "error.expected.int"])
  | ["name", name] -> Ok { name; age =3D <=
span style=3D"color: #242521; background-color: #fcf7ef;">None }
  | ["age", age] ->
    (match int_of=
_string age with
    | age -> =
Error ["name", "error.required"]
    | exception <=
span style=3D"color: #242521; background-color: #fcf7ef;">Failure _ =
-> Error ["age", "error.expected.int"; "name"<=
/span>, "error.required"])
  | _ -> Erro=
r ["name", "error.required"]

And this is a form with only two fields. You can imagine how convoluted the= logic would be for more complex forms. Of course, you might just decide to= use List.assoc_opt and build up the validation errors, but ev= en that can get tricky. So if you are making heavy use of HTML forms, a hel= per module that takes care of all these validation details can be very usef= ul. Enjoy!

Second beta release of OCaml 5.3.0

Archive: https://discuss.ocaml.org/t/second-beta-release-of-ocaml-5= -3-0/15700/1

octachron announced

One month after the release of the first beta for OCaml 5.3.0, we are rele= asing a second and hopefully last beta release for OCaml 5.3.0 .

The most notable changes for this second beta are probably a handful of typ= e system bugfixes. In particular, those fixes revert a change of behaviour = in the first beta when pattern matching GADTs with non-injective type param= eters.

We also have a C++ header compatibility fix and the restoration of some con= figuration variable in Makefiles for the sake of backward compatibility.

Overall, the release is converging and we are expecting to have a first rel= ease candidate around the middle of December. The progresses on stabilising= the ecosystem are tracked on the opam read= iness for 5.3.0 meta-issue.

Meanwhile, the second beta release of OCaml 5.3.0 is here to help you update your software and libraries ahead of the release (see below for the install= ation instructions).

The full release is expected before the end of December.

If you find any bugs, please report them on OCaml's issue tracker.

If you are interested in full list of features and bug fixes of the new OCa= ml version, the updated change log for OCaml 5.3.0 is available on GitHub.

Happy hacking, Florian Angeletti for the OCaml team.

Installation Instructions

The base compiler can be installed as an opam switch with the following com= mands on opam 2.1 and later: 

opam update
opam switch create 5.3.0~beta2

The source code for the beta is also available at these addresses:

  • Fine-Tuned Compiler Configuration

    If you want to tweak the configuration of the compiler, you can switch to t= he option variant with: 

    opam update
opam switch create <switch_name> ocaml-variants.5.3.0~beta2+options &=
lt;option_list>

    where option_list is a space separated list of ocaml-opt= ion-* packages. For instance, for a flambda and no-flat-float-array = switch: 

    opam switch create 5.3.0~beta2+flambda+nffa ocaml-variants.5.3.0~beta2+opti=
ons ocaml-option-flambda ocaml-option-no-flat-float-array

    All available options can be listed with opam search ocaml-option.

Changes Since The First Beta

  • Type system fixes
    • #13501: Reg= ression on mutually recursive types caused by #12180. Resuscitate Typedecl.update_type. (Jacques Garrigue and Takafumi Saikawa, review by Florian Angeletti, Richard Eisenberg and Gabriel Scherer)
    • #13495, #13514: Fix typech= ecker crash while typing objects (Jacques Garrigue, report by Nicol=C3=A1s Ojeda B=C3=A4r, review by Nicolas Ojeda B=C3=A4r, Gabriel Scherer, Stephen Dolan, Florian Angeletti)=
    • #13598: Fal= sely triggered warning 56 [unreachable-case] This was caused by unproper protection of the retyping function. (Jacques Garrigue, report by T=C3=B5ivo Leedj=C3=A4rv, review by Florian An= geletti)
  • Configuration fixes
    • (breaking change) #12578, #12589, #133= 22, +#13519= : Use configured CFLAGS and CPPFLAGS only during the build of the compiler itself. Do not use them when compiling third-party C sources through the compiler. Flags for compiling third-party C sources can still be specified at configure time in the COMPILER_{BYTECODE,NATIVE}_{CFLAGS,CPPFLAGS} configuration variables. (S=C3=A9bastien Hinderer, report by William Hu, review by David Allsopp)
  • C++ header compatibility
    • #13541, #13591: Fix header= s for C++ inclusion. (Antonin D=C3=A9cimo, review by Nick Barnes, report by Kate Deplaix)
  • Compiler library bug fix
    • #13603, #13604: fix source= printing in the presence of the escaped raw identifier \#mod. (Florian Angeletti, report by Chris Casinghino, review by Gabriel Scherer)<= /li>

New release of Monolith

Archive: https://discuss.ocaml.org/t/ann-new-release-of-monolith/15701/1

Fran=C3=A7ois Pottier announced

I am pleased to announce a new release of Monolith, a library that = helps perform strong automated testing of OCaml libraries. 

opam update
opam install monolith.20241126

The changes are as follows:

  • The documentation of the specification combinators has been re-organized in sections and subsections. Finding the desired combinator should now be easier.
  • The new combinator naive_array offers limited support for = arrays.
  • The new combinator naive_seq offers limited support for se= quences (that is, for the type constructor Seq.t).
  • The new combinator pair is a synonym for ( *** ).
  • The new combinator triple offers support for triples.
  • The new combinator either offers support for the type cons= tructor Either.t.
  • The new combinators iter, foldr, foldl<= /code>, iteri, foldri, foldli offer support for iteration functions.
  • An unintentional and undocumented limitation has been fixed: so far, us= es of the combinator map_into would work only at the root of the spe= cification or in the right-hand side of an arrow ^>. It should now be = possible to use map_into under other combinators that expect a deconstructible specification, such as ^!> (in the right-hand side), = ( *** ), option, result, list, etc. This improvement affects not o= nly map_into, but also a number of other combinators that are defined in terms of map_i= nto.
  • Monolith now requires OCaml 4.12 or later.
  • In Makefile.monolith,
    • the default switch is changed from 4.11.1 to 4.14.2; this can be overridden by defining SWITCH;
    • make test automatically disables the MacOS crash reporter;=
    • the use of ulimit -s is abandoned.

Jsont 0.1.0 =E2=80=93 Declarative JSON data manipulation for O= Caml

Archive: https://discuss.ocaml.org/t/ann-= jsont-0-1-0-declarative-json-data-manipulation-for-ocaml/15702/1

Daniel B=C3=BCnzli announced

It's my pleasure to announce the first release of the jsont libary:=20

Jsont is an OCaml library for declarative JSON data manipulation. It provid= es:

  • Combinators for describing JSON data using the OCaml values of your cho= ice. The descriptions can be used by generic functions to decode, encode, q= uery and update JSON data without having to construct a generic JSON repres= entation.
  • A JSON codec with optional text location tracking and layout preservati= on. The codec is compatible with effect-based concurrency.

The descriptions are independent from the codec and can be used by third-pa= rty processors or codecs.

Jsont is distributed under the ISC license. It has no dependencies. The cod= ec is optional and depends on the bytesrw library. The JavaScript support is option= al and depends on the b= rr library.

The library has been used in practice but it's new so a few adjustments may= be needed and more convenience combinators added.

The library also enables quite a few things that I did not have the time to= explore like schema description generation from descriptions, quasi-stream= ing JSON transformations, description generation from dynamic type represen= tations, etc. Lots of this can be done outside the core library, do not hes= itate to get in touch if you use the library and find interesting applicati= ons or pesking limitations.

This first release was made possible thanks to a grant from the OCaml Software Foundation. I also thank my donors for their support.

Best,

Daniel

P.S. I think that the technique used by the library, which I dubbed fina= lly tagged is interesting in itself. You can read a paper about it here along wi= th a smaller, self-contained, implementation of what the library does.

Tiny educational concurrent I/O and promises library

Archive: https://discuss.ocaml.org/t/tiny-educati= onal-concurrent-i-o-and-promises-library/15703/1

Mikhail announced

I like Lwt. It's a fantastic= library, but how does it work? I spent a few days studying its source code= .=20

Finally, inspired by the implementation of Lwt and the CS3110 chapter, 8.7. Promises. I wrote a maxima= lly stupid tiny-asy= nc-lib library.=20

Maybe you may be interested in this naive implementation.=20

Examples of use

let () =3D=20
  Engine.run main begin
    let* () =3D <=
span style=3D"color: #444fcf;">Io.(write_all stdout) "Hi! What's your name? " in
    let* name =3D Io.=
(read_line stdin) in
    Io.(write_all stdout) ("Hello, " ^ name ^ "!\n")
  end

let read_and_print_file =
filename =3D=20
  Io.(read_file filename >>=3D=
 write_all stdout)

let _ =3D
  Engine.run begin
    let filenames =3D [ (* ... *)=
 ] in=20=20

    filenames
    |> List.map read_and_print_file
    |> Promise.join
  end

Implementation details

The first key abstraction of the whole library is, of course, Promise. Promise is a= n abstraction for synchronizing program execution in concurrent evaluations= . In simple terms, it's an abstraction over callbacks. Promises allows us t= o build (monadic) sequence evaluations inside of non-sequence evaluations. 

(* promise=
.ml *)

type 'a t =3D { mutable state: 'a state }=20=20

and 'a state =3D=20
  | Fulfilled of 'a=20
  | Rejected of exn
  | Pending of 'a callback=
 list=20

and 'a callback =3D 'a state -> unit=20

Promises are represented as a mutable record with three possible states: fu= lfilled (contains a value), rejected (contains an exception), and pending (= contains callbacks).=20

Callbacks are functions that are called when a promise is resolved. So when we bind, if the promise is in pending state, we add a = callback that calls the following monadic sequence when the promise is reso= lved. 

(* io.ml *)

let sleep delay =3D
  let p, r =3D=
 Promise.make () in

  Engine.(on_timer instance) delay (=
fun handler ->
      Engine.stop_handler handler;
      Promise.fulfill r ());

  p

The second key abstraction is an asynchronous I/O engine that polls I/O events and disp= atches them to handlers. Original Lwt has few engines (like based libev, se= lect, poll), but I hardcoded a [select](https://en.wikipedia.org/wiki/Select_(Unix))-based= engine inspired by Lwt_engine.select_based.=20

The typical async engine in internals has an event loop. At each iteration = of the event loop, the engine polls for new events and calls handlers to ha= ndle them.=20 

(* engine.=
ml *)

let iter engine =3D
  (* ... *)

  let readable_fds, w=
ritable_fds, _ =3D
    Unix.select readable_fds writabl=
e_fds [] =
timeout
  in

  engine.sleepers <- restart_sleepers now engine.sleepers;

  invoke_io_handlers engine.wait_readable readable_fds;
  invoke_io_handlers engine.wait_writable writable_fds

How to execute I/O promise? It's not a big deal.=20 

(* engine.=
ml *)

let rec run promise =3D
  match Promise.state promise with
  | Fulfilled value -> value
  | Rejected exc -> raise exc
  | Pending _ ->
      iter instance;
      run promise

We just need to loop the event loop until the promis is resolved.

It's just a toy! I'm not an expert in such things, so the library is very n= aive and tries to mimic Lwt. But I think it's a good demonstration.=20

Repository https://github.com/dx3= mod/tiny-async-lib

Thank you for your attention!

Eliom 11.1: Towards Web Assembly support

Archive: https://discuss.ocaml.org/t/eliom-11-1-towards-web-as= sembly-support/15704/1

Vincent Balat announced

Eliom 11.1 has been released recently. This minor release brings compatibility with Web Assembly and the upcoming = version of js_of_ocaml. Ocsigen Toolkit and Ocsigen Start have been updated as well.

Stay tuned for further announcements concerning client-server Web and mobil= e apps in Ocaml with Web Assembly!

Links:

Areas and Adversaries

Archive: https://discuss.ocaml.org/t/ann-areas-and-adversaries/15706/1

Rapha=C3=ABl Proust announced

I figured people might be bored of British pub names by = now so I did another thing: a generator for titles of table-top role-play= ing games. 

$ opam install areas-and-adversaries
...
$ areas-and-adversaries
Woods & Wizards

The code is on Gitlab: https://gitlab.com/raphael-proust/areas-and-adversaries

It was a good excuse to experiment with non-dune build systems (to scope th= ings out). I went for a plain Makefile in the end which works well.

I also wanted to figure out a better way to embed data in an executable. I = ended up wondering about moving as much of the processing as possible into = the build phase. What I ended up with is a small program which prints a com= pilation unit (.ml) which has mostly array literals. Still hav= e some open questions on that, any input welcome:

  • Should I have used meta-ocaml to print the code? The data/munch.m= l would probably be more readable, but the build probably less.
  • How could I generate this kind of processed-data code for data-structur= es which don't have a literal (maps, sets, hash tables, etc.)? How can I mi= nimise the initialisation cost of the program for such situations?

MariaDB 1.2.0

Archive: = https://discuss.ocaml.org/t/ann-mariadb-1-2-0/15709/1

Petter A. Urkedal announced

I'm please to announce a new release of the mariadb package, which provides client bi= ndings for MariaDB and MySQL. See the full release notes below.

This is also to announce that I have taken over maintenance of the project.= Currently I am the sole maintainer (and I usually use PostgreSQL for my o= wn deployments), so if someone has the time en interest to contribute, let = me know. The main focus from my side is to keep the project up to date and= stable, rather than making major changes.

Release notes:

  • Added Stmt.start_txn (#59 by Corentin Leruth).
  • Added Res.insert_id as binding for mysql_stmt_insert= _id (#58 by=20=20=20=20=20=20=20=20=20=20=20=20 Corentin Leruth).
  • Updated to support recent OCaml versions (#45 by @kit-ty-kate).
  • Fixed too-early retrieval of statement metadata (#41 by Albert Peschar)= .
  • Fixed decoding bug for the integer type (#54 by Raman Varabets, tested= =20=20=20=20=20=20=20=20=20 by #61 by Corentin Leruth).
  • Fixed a memory leaks related to result metadata (#39 by Albert Peschar)= .
  • The build system is now dune and dune-configurator (#52 by Petter A.=20= =20=20=20=20=20=20=20=20=20=20 Urkedal) and some of the examples have been converted to a test suite=20=20= =20=20=20=20=20=20=20=20 (#60 by Petter A. Urkedal).
  • The project has been transferred to ocaml-community with Petter A.=20= =20=20=20=20=20=20=20=20=20=20=20=20 Urkedal as the new maintainer.

Proposed Package Archiving Policy for the opam Repository

Archive: https://discuss.ocaml.org/t/propose= d-package-archiving-policy-for-the-opam-repository/15713/1

Hannes Mehnert announced

It is my please to announce the proposed package archiving policy in the na= me of the opam-repository maintainers.

Context

The opam repository differs from nearly all other programming-language-cent= ric package repositories in that it is manually curated by volunteer mainta= iners and protected by a robust continuous integration system that (general= ly) ensures published packages work as expected across a large matri= x of supported platforms.

Over the past few years the repository has kept growing steadily, when not = accelerating, and this has started raising questions about the size, weight= and sustainability of the repository and its processes. Last year, Hannes Mehnert requested comments on a = proposed = initiative to improve the sustainability and quality of the opam packag= e repository on the long term.

Problem

The problem, in a nutshell, is that the opam-repository will k= eep steadily growing, using an increasing and substantial amount of space a= nd inodes. Every opam user needs to invest a large amount of computational = resources for the solver, every time they want to install or update a packa= ge. Additionally, a large amount of computational resources are spent in th= e continuous integration process and yet a lot of the packages have become = stale or uninstallable.

Solution

After muc= h deliberation, the discussion converged on a solution: introduce a pac= kage archiving policy and supporting processes, to periodically identify an= d prune unmaintained and broken packages from the repository. This will imp= rove the performance of the opam solvers, of the opam-repo CI, and most imp= ortantly improve the quality of the package repository, while keeping a sor= t of immutability of the repository content and preserving the usability of= historical packages for the users that want or need them.

The opam repository maintainers propose a policy.

The currently empty repository archive has been created, waiting for packages to be m= oved.

Call to action

If you maintain packages in the opam-repository, you can help by defining y= our maintanence intent: add a new field x-maintenance-intent t= o your opam file(s) (the most recent release of your package is sufficient = - please also put this field in your git repository so it will be part of f= uture releases). The value is defined in the policy.

Roadmap

All announcements will be on discuss.ocaml.org with the opam-repository tag= . If you like to follow these announcements, keep your eyes at the opam-repository tag.

  • December 1st 2024: announcement of this proposal
  • December 15th 2024: announcement of the packages affected by Phase 1 (u= ninstallable packages ("available: false", "flags: avoid-version" or "depre= cated", "opam admin check –installable", does not compile – o= pam health check https://check.ci.o= caml.org/)
  • January 1st 2025: Phase 1 cutting point: packages are moved to opam-rep= ository-archive
  • January 15th 2025: announcement of the packages affected by Phase 2 (OC= aml lower bound 4.08)
  • February 1st 2025: Phase 2 cutting point: packages are moved to opam-re= pository-archive
  • February 15th 2025: initial spring cleaning, announcement of packages (= based on maintenance-intent)
  • March 1st 2025: spring cleaning cutting point: packages are moved to op= am-repository-archive
  • Every quarter: repeat Phase 3
  • Every year: reconsider Phase 2 with an increased OCaml lower bound

We now invite members of the OCaml community who may not follow the ocaml-r= epository issues to review our plans and submit comments, questions, or sug= gestions.

Thank you in advance for your support!

Acknowledgment

Thanks to the following individuals for valuable input and contributions to= the planning process (sorry in case we forgot you):

  • Marcello Seri
  • Shon Feder
  • Thomas Gazagnaire
  • kit-ty-kate
  • Weng Shiwei =E7=BF=81=E5=A3=AB=E4=BC=9F
  • Marcus Rohrmoser
  • Reynir Bj=C3=B6rnsson
  • Stephen Sherratt
  • Simon Cruanes
  • Marek Kubica
  • Rapha=C3=ABl Proust
  • Romain Beauxis
  • Yawar Amin
  • Anil Madhavapeddy
  • Boning D.
  • Mathieu Barbin
  • Hannes Mehnert

capnp-rpc 2.0

Archive: = https://discuss.ocaml.org/t/ann-capnp-rpc-2-0/15739/1

Thomas Leonard announced

I'm pleased to announce the release of capnp-rpc 2.0, an OCaml implementation of= the Cap'n Proto RPC specification.

If you haven't used the library before, please see the documentation and tutoria= l. Cap'n Proto RPC aims to provide secure, efficient, typed communicati= ons between multiple parties.

The main change in this version is the switch from Lwt to Eio for concurren= cy. The echo benchmark is about 40% faster than before. This isn't because = Eio is actually that much faster than Lwt, but more because it has better p= rofiling support so spotting problems was easier. See https://roscidus.com/blog/blo= g/2024/07/22/performance/ for an example:

3D"capnp-eio-slow-zoom1-debug.png"

There is a capnp-rpc-lwt compatibility package that provides t= he old Lwt API using the new Eio version, allowing libraries using the old = API to be used in applications using the new code, without having to update= everything at once.

To migrate to the new version (checking everything still works after each s= tep):

  1. First, update to capnp-rpc 1.2.4 (this ensures you are using the newer = mirage-crypto API, to get that migration out of the way first).
  2. Switch your application (that sets up the networking) to capnp-rpc-unix= 2.0.
  3. Migrate client and server code away from capnp-rpc-lwt when convenient.=

For more detailed instructions, see the changelog.

Here's an example of the changes needed in the solver-service project:

Other OCaml News

From the ocaml.org blog

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

Old CWN

If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a 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.

--=-=-=--