From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 6AZ4IIaa02W1gAEAe85BDQ:P1 (envelope-from ) for ; Mon, 19 Feb 2024 19:14:30 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id 6AZ4IIaa02W1gAEAe85BDQ (envelope-from ) for ; Mon, 19 Feb 2024 19:14:30 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=arctype.co header.s=mail header.b=KsZYLfBM; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=reject) header.from=arctype.co ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1708366470; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=N2mvGldi0Vb3tgW7SeUlGzCWn7fiUQBn6DYiEqhUK6Q=; b=CMUw0VkgEq6+BNA9Ehajqsi3rQKHX92+AYTuzqcWkq4uYuVnUobmUebvu6WEW0WmKeLsrz 5HySqLd8tPM5/qwT5MNIMl7wYg+Kpde2+DdgSZg/hgT5Dw+/0fvAFgcp8xyar837RFtcUl 6S/xnfp5xVxmk4O+2K9ZIHylcdZKoJHgDl+T0WMdV5V4/OcIK7+NSPgOHIa9FFUCV9ToF8 Zh8Y2e2H1FdAPjCX49QdN/zE6PEpcVe1HNUYRlgaVXRGZBc85Sd8D/d1DwLmaSOJGhCGqb VrCOav4GudT1aSllD04rvcpGvj+C7QcnntZuPJ/FYgxvrxjljFCg2Nb00eWVbw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=arctype.co header.s=mail header.b=KsZYLfBM; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=reject) header.from=arctype.co ARC-Seal: i=1; s=key1; d=yhetil.org; t=1708366470; a=rsa-sha256; cv=none; b=B+d2DPP9GQCgnlpSfH14hN75eA/TylnQnbdZxJ5AIwHW5xCkBfNJwYfUA6TE38mDHma98S PbUljJvVa4rSxLlgeZoQwSm6WIndLw66QZ1VPFMERcd8U5ArqjZhgRHnQuS3Kp52j8t1ai /6/az94iJgdmGwkRJII9egYSxwvMkLrFD1Rb7E1yYu9JWkRZWESflSdSVf4MVpIVKGZS9u z6tWx6Ki+BrI+UBBIxyr0uzJdpSWIbuSVdlcZKKEkjy5Kzqjf7Q5ZfjkydZMcT/5xLUiUu ojm0u2XL9wT+kJpIDHWC52m66j2rEsR4R5bq5mQXuKQL9Kfl6lj9QzbI7vAOgw== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 731EB715BE for ; Mon, 19 Feb 2024 19:14:30 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rc89H-0001jQ-95; Mon, 19 Feb 2024 13:13:51 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rc89F-0001j2-GH for guix-devel@gnu.org; Mon, 19 Feb 2024 13:13:49 -0500 Received: from mail.arctype.co ([138.68.9.245]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rc89D-0004BK-As for guix-devel@gnu.org; Mon, 19 Feb 2024 13:13:49 -0500 Received: from authenticated-user (mail.arctype.co [138.68.9.245]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.arctype.co (Postfix) with ESMTPSA id 6A59E13B18E; Mon, 19 Feb 2024 18:13:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arctype.co; s=mail; t=1708366391; bh=N2mvGldi0Vb3tgW7SeUlGzCWn7fiUQBn6DYiEqhUK6Q=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=KsZYLfBMDryxzu6JHzcos2wcEzMOLc+ZEcrPYKWg+fkySA2zutf8b8FrLYJrmsJng V8708Vdp3MGTErr8z6jy4qw2wePja6lu69lU25MjK1QTfKabmJQlbuILI84NXSUiZa yWhxMMW/1gXBWcAQTaVE9SgLRVP1lyafCz8Bhs07+7epyl13KUjhiWO9BCO0nuq1KO vtZeH8jq5h1yRNoEDw1lVGLMMAIoY721FHNcja5ECULv9CCi+P6CJYunFbaLGZJO4O mNAQ39HScXVpFFvFUvvK5vuReZVwhcLv0IDOK7qaZMKQwOprDTiybePteARWpU0aUN IHKv+l2ffkQmA== Date: Mon, 19 Feb 2024 10:13:09 -0800 (PST) From: Ryan Sundberg To: Steve George Cc: guix-devel@gnu.org, r0man , Reilly Siegel , Maxime Devos Message-ID: In-Reply-To: References: Subject: Re: Proposal to turn off AOT in clojure-build-system MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Correlation-ID: Received-SPF: pass client-ip=138.68.9.245; envelope-from=ryan@arctype.co; helo=mail.arctype.co X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -5.81 X-Spam-Score: -5.81 X-Migadu-Queue-Id: 731EB715BE X-TUID: cBhnVkNz712H As a daily Clojure programmer using Guix the default 'off' makes sense. The= only situation where AOT compilation is useful is in the final runnable ap= plication programs, and even then, its often incompatible with AOT compilat= ion in subtle ways. Having libraries aot compiled not only adds incompatibi= lity (including which java the library was built for, which creates a "leas= t common denominator problem which JDK you can use for the final build) but= also wastes time and energy. Identifying AOT compilation bugs can also be extremely frustrating to packa= ge maintainers as the underlying cause is usually not obvious. In my experi= ence using AOT is the exception rather than the rule; it is a nice optimiza= tion when practical for release engineering, but typically the juice is not= worth the squeeze. Sincerely, Ryan Sundberg Feb 19, 2024 3:48:54 AM Steve George : > Hi, >=20 > Guix's clojure-build-system turns on AOT compilation by default. I would = like to advocate that 'as a distributor' we should *not* ship Clojure code = AOT'd, so we should change the default. >=20 > This has been discussed previously. In #56604 r0man noted that AOT compil= ation should not be on by default [0], Reilly makes the same point in #5376= 5 [1]. >=20 > Maxime makes the point that where a compiler is available it should be us= ed [2] and that if it doesn't work it's a bug: >=20 > =C2=A0 "if a Clojure library misbehaves when AOT-compiled, without additi= onal context, that seems like a bug in the Clojure library to me (or the AO= T-compilation code). >=20 > The perspective in the Clojure community is quite different from Guix's o= n a number of fronts. There's not much discussion about offline builds, rep= roducibility or code coming from Distributions. The internalised perspectiv= e is that you use the build tools to download libraries directly from Cloja= rs (a Maven repo) and developers create a final uberjar for production usag= e Consequently, there is no specific statement saying 'Distributors should = not AOT libraries' that I can point to. But, I would like to draw attention= to this thread on Clojureverse as the best source I could find: >=20 > Alex Miller is the main community manager for Clojure, and is a maintaine= r of the core libraries, so his perspective is key. He notes that, AOT code= is tied to *specific versions of Clojure*: >=20 > =C2=A0 "AOT'ed code is that it is inherently the product of a particular = version of tthe Clojure compiler ... I would recommend NOT AOT compiling li= braries" [4] >=20 > In the same thread thheller, who is the maintainer of the most popular Cl= ojureScript tooling,=C2=A0 notes you cannot mix AOT and non-AOT libraries [= 5]: >=20 > =C2=A0=C2=A0=C2=A0 "you cannot just ship your library AOT compiles as it = would also contain clojure.core. Clojure AOT current ... can not load clj f= iles from .class files. So AOT produces the class files and will fail if on= e of the dependent classes is missing although the .clj file is present" >=20 > I believe this means that with AOT code on, any user who installs a diffe= rent version of Clojure from the one that we used to AOT the libraries *may= * have problems. And, that we can't have trees where some part is AOT'd but= a dependency is not. Finally, there is no expectation in the Clojure commu= nity that this is a bug, consequently it will not be fixed. Therefore, we s= hould change to default to AOT off. >=20 > What do people think, does this make sense? >=20 > Thanks, >=20 > Steve / Futurile >=20 > [0] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D56604#5 > [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D53765#290 > [2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D53765#293 > [4] https://clojureverse.org/t/deploying-aot-compiled-libraries/2545/6 > [5] https://clojureverse.org/t/deploying-aot-compiled-libraries/2545/3 > [5] https://gist.github.com/hiredman/c5710ad9247c6da12a99ff6c26dd442e