From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.user Subject: Re: Running Compiled Guile Objects Date: Sun, 15 Dec 2024 01:31:44 +0900 Message-ID: References: <87frmroykg.fsf@free-comp-shop.com> <20241214140118.od1H2D00P1Y3F3G01d1JPj@xavier.telenet-ops.be> <20241214155337.oetc2D0091Y3F3G06etclL@albert.telenet-ops.be> <20241214171059.ogAy2D00B1Y3F3G01gAyTM@laurent.telenet-ops.be> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37172"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Keith Wright , "hakancandar@protonmail.com" , "guile-user@gnu.org" To: Maxime Devos Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Sat Dec 14 17:32:27 2024 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tMV46-0009Xa-AB for guile-user@m.gmane-mx.org; Sat, 14 Dec 2024 17:32:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMV3m-0006CN-OH; Sat, 14 Dec 2024 11:32:06 -0500 Original-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 1tMV3k-0006C3-38 for guile-user@gnu.org; Sat, 14 Dec 2024 11:32:04 -0500 Original-Received: from mail-pl1-x62d.google.com ([2607:f8b0:4864:20::62d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tMV3f-0002L6-Dq for guile-user@gnu.org; Sat, 14 Dec 2024 11:32:03 -0500 Original-Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-21683192bf9so26257955ad.3 for ; Sat, 14 Dec 2024 08:31:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734193916; x=1734798716; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=syosdLXnJqUzxp1uAdjN94mQ+kX2BwtmDcWUJOxz4Ek=; b=DTmH2dwDNPO80sTyhlEDbFBD7rahFWGKEfPjvM3ow/q65DxML96HMbgR/36D7svvJB xH03tFBQw3f5fVuFs/4vhWp4OeV1CEj/tsudiuLdos2OD1byZGEzyXTW0y7Ev87bGq8F JmnpXRMZ+PKNODBiGrTZurYFT7khjZIWbcQ/vzguWeGNQuMA+8aIGYnTa9NWHPz4MNB7 3LXYIjKLa2g7lAF61CqcFx3rz8ZMU7JiGUdSXmRemMXZYU2G+hKK8h2LzLUrEBC49DBE 1nf6jqnFs+7XHoSSTMdzA1HwL68kN+UzcUsq1lDcPop/9ghzW3vyvmu3FEUe/tMKJbnm B5Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734193916; x=1734798716; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=syosdLXnJqUzxp1uAdjN94mQ+kX2BwtmDcWUJOxz4Ek=; b=Mt5jDjTPMRvQRW/5AOqPOQE0oI2ymk3j8bfsDEMWCUxD24wUZYh5rj8ab3kZDqaUfA Z/b6ThxCin7p3igo2x05EfXuTj50uCWw85/u9t0O2mZ5XfnIBnfvjzctEBlcUCqyiLxw IF5T/D8PdY8jIFHprcL0c5uvZ7C6bb5CkDBqhtYi3asJjR7usAM4DrFulMORJKCZq0aw 9xzw7+/9bqkHoVTJcxMFDNHQBCoVkU8uVmJkCm60Y3NMfvM5YfUGfb5KLE6TSUaWhXrA KelO1dfRaPCYCz1nA2elI2Vp8cvvIGDVXRKZfig7zoIRJTVh1vQUdoY2XpUHD55s0mBd Romw== X-Forwarded-Encrypted: i=1; AJvYcCVzmEa0FIKE4PXOrfoLJjtFHkOJtSljGhipGLtsf/CqjQ9oNqYSVEcmuisAdRlv00WNdfjoUr3mGl1t@gnu.org X-Gm-Message-State: AOJu0YwxnaFZMz6yHLgJBT9PcVTB+iEMquDRKJEZINbKVOPeQTmM5953 ecTE0lZauf+UjbV6Ttz7vT9cUlXS35VfRaANVKajq6ikRbuEXY4abfKK/xXBa6HnLhlmqf9dCR4 XTzYMpojXt84BZDDhbipzBoRnoZ0= X-Gm-Gg: ASbGncsTYAdDrvdXPrf34Y4JdRPrOw5mG1GBO7h/VfDS6pkqyzPhWsniTx+hvEj4+cR wHUlRo68fvW2tW5Xux0Y1qFgB0zDo4l3J0PIjzw== X-Google-Smtp-Source: AGHT+IGLYykvigSNOSaiqjya0eQV8JUZOXazXQl1IbkAtG0+HNlhGgNq+R0hzWCxcZ8N7GaP6l1MAF33L5vIvVYzqPA= X-Received: by 2002:a17:902:fb8d:b0:216:2f91:92c7 with SMTP id d9443c01a7336-2189298a122mr78354965ad.12.1734193916416; Sat, 14 Dec 2024 08:31:56 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::62d; envelope-from=nalaginrut@gmail.com; helo=mail-pl1-x62d.google.com 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.user:19989 Archived-At: > You can indeed modify the loading paths from within Guile (I previously mentioned this myself). But this doesn=E2=80=99t help with loading the firs= t .go (so it=E2=80=99s not an easier way, it=E2=80=99s not a way) No, my suggestion to modiy load path on the fly is not the way to help load first .go, but a regular way to take advantage of the cache. This suggestion implies one give up the manual loading. So of course it's not the way as you thought. On Sun, Dec 15, 2024, 01:26 Nala Ginrut wrote: > > Guile doesn=E2=80=99t care about whether it is a cache or not, as long = as it has > the .go, the timestamps are ok, and (IIRC) corresponding .scm exis. > > I wonder if you have tested the given example. Guile doesn't load .go as > the dependency, but .scm. > > I think I have to confirm that you don't want to trigger auto-compilation= , > since your situation is the default cache dir lacking of permission, righ= t? > > If so, my example showed the simple bypass may not a proper way to go. > > Best regards. > > On Sun, Dec 15, 2024, 01:20 Nala Ginrut wrote: > >> > You missed =E2=80=98-C=E2=80=99 (load-compiled-path) >> >> I didn't miss load-compiled-path here, I think you confused with -c. >> -C obj specified the current load compiled path to "./obj". >> >> On Sun, Dec 15, 2024, 01:10 Maxime Devos wrote: >> >>> >>> - IMHO, the manually .go loading will cause more issues. >>> - First, here's a fact: manually loading will not bypass the >>> intrinsic .go caching. Only the first .go will, and the rest of the = deps >>> chain will still be managed by the intrinsic caching. [snip] >>> >>> [snip: module (a) (a.scm / a.go) uses module (b) (b.scm / b.go)) >>> >>> I don=E2=80=99t see =E2=80=98more issues=E2=80=99 here. The (non-)issue= you mention exists >>> regardless of whether module a is loaded as =E2=80=98a.scm=E2=80=99 or = as =E2=80=98b.go=E2=80=99. Also >>> autocompilation causes its own issues, if it requires things in the >>> environment during compilation that aren=E2=80=99t available at time or= use (e.g. a >>> C pre-processor in case a library using macros from a FFI library, wher= e >>> you don=E2=80=99t want the C pre-processor to have to stay installed wh= en using the >>> binding library), or when the compilation is messy, e.g. it uses files = from >>> the build directory that aren=E2=80=99t installed in the .scm and .go d= irectories >>> (and don=E2=80=99t make sense to be installed there). >>> >>> And in the situation where all used modules are precompiled and already >>> in the load paths (e.g. modules of Guile itself, or installed with pack= age >>> manager), then no caching happens at all. >>> >>> - - if you have two module, a.scm and b.scm, a imported b's function >>> to use. >>> - the .scm are in ./mod directory. >>> - compile them and put into ./obj/mod directory. >>> - guile -C obj -L . >>> - (load-compiled "obj/mod/a.scm.go") >>> - the deps have to be loaded from the scm path specified by -L. IIRC >>> there is no way to load deps from .go, unless you provide a manual c= aching. >>> >>> You missed =E2=80=98-C=E2=80=99 (load-compiled-path). You can point thi= s to a cache if >>> you wish, but it doesn=E2=80=99t need to be a cache. Guile doesn=E2=80= =99t care about >>> whether it is a cache or not, as long as it has the .go, the timestamps= are >>> ok, and (IIRC) corresponding .scm exis. >>> >>> - So the problem is, if you want to bypass the caching, you have to >>> provide your manual caching comprehensively. >>> >>> No. You can disable caching without providing manual caching. E.g., in >>> case of %.go:%.scm Makefile rules (+ dependency information which in >>> principle could be automatically generated by guild, but currently isn= =E2=80=99t >>> yet), make takes care of compilation. Because of its local nature (no >>> shared cache) (^), lack of capacity limits (no time limits, no size lim= its) >>> and its aesthetics (it=E2=80=99s just compilation) (*), this is not a c= ache system. >>> >>> (*): for a comparison: you can compile C code to a shared and install i= t >>> in /usr/lib without /usr/lib being a cache =E2=80=93 being a cache is m= ore about >>> how it is populated and maintained than it is about what it happens to >>> contain. >>> (^): not a strict requirement for a cache, but it=E2=80=99s an indicati= on when >>> the =E2=80=98known cache=E2=80=99 (that thing in .cache/) is a differen= t and more global >>> thing. >>> >>> Another option is to only precompile the a.scm (and not additional >>> dependencies) and disable autocompilation (when there=E2=80=99s only a = single file >>> to take care of, comprehensive is trivial). >>> >>> A third option is to use potentially outdated .go (unfortunately Guile >>> doesn=E2=80=99t fully separate caches from precompiled code, so beforeh= and you need >>> to update the timestamps to make Guile accept them). This can then be >>> separation of =E2=80=98code I'm currently writing, which might be in a = not-ready >>> state, but I already saved it to not loose it in case the computer need= s to >>> suddenly shut down=E2=80=99 and =E2=80=98latest =E2=80=98good=E2=80=99 = version of the code =E2=80=93 might be >>> incomplete, but is ready for testing=E2=80=99. (Other methods exist too= , but this >>> can be convenient.) >>> >>> - The relative easier way would be modify the loading path on the >>> fly with Guile related API. >>> >>> You can indeed modify the loading paths from within Guile (I previously >>> mentioned this myself). But this doesn=E2=80=99t help with loading the = first .go >>> (so it=E2=80=99s not an easier way, it=E2=80=99s not a way) =E2=80=93 = if a.scm sets up the load >>> paths (including compiled path), then by the time that Guile can know w= here >>> a.go is located, it=E2=80=99s too late for that. So, either you need to= : >>> >>> (0) not precompile a.scm (it=E2=80=99s pointless) (and for dependencie= s adjust >>> load paths when needed, in invocation or in a.scm) >>> (1) install a.go somewhere in the standard load-compiled-path (not >>> always possible) and just ask guile to load a.scm (-> guile loads a.go >>> instead) >>> (2) add =E2=80=98-C insert-go-directory-here=E2=80=99 to the guile invo= cation >>> (straightforward, but not the best option) and load a.scm (-> guile loa= ds >>> a.go instead) >>> (3) tell Guile to load a.go, and let a.go set load-compiled-path (& >>> load-path) to find remaining dependencies >>> >>> Of these four options, (0) and (3) have the most convenient invocation. >>> Of those two options, (3) has the least re-compilation. By these criter= ia, >>> (3) is the best. >>> >>> Best regards, >>> Maxime Devos >>> >>> >>> >>