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:20:25 +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="38353"; 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:21:35 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 1tMUtb-0009rL-Jf for guile-user@m.gmane-mx.org; Sat, 14 Dec 2024 17:21:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMUsq-0004kb-75; Sat, 14 Dec 2024 11:20:48 -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 1tMUsm-0004kC-Se for guile-user@gnu.org; Sat, 14 Dec 2024 11:20:44 -0500 Original-Received: from mail-pj1-x1031.google.com ([2607:f8b0:4864:20::1031]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tMUsk-0007K0-LN for guile-user@gnu.org; Sat, 14 Dec 2024 11:20:44 -0500 Original-Received: by mail-pj1-x1031.google.com with SMTP id 98e67ed59e1d1-2ee8aa26415so2424476a91.1 for ; Sat, 14 Dec 2024 08:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734193238; x=1734798038; 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=fYC6LT4dL4X8l2tzCQ1hTL2Td/BaM3eFhCAaTNKigRM=; b=f9BSNg5PHV46NXg1BJR3LOfnImk3tXDfMHFriFzMJ5rkz8ILnZ7TvPeV4/cuNnQdHV ohbtFivEml3uaAIcQnYnyG+nrpPrhX09eOa6shyyYm3wTzg2GRqm3Bixdex3fUxQZmiW PEoG9EVDHxB6eFF191O/IvpQoPIghfDUWe/3KHqsArhowo77ITkTelRfVicWT6sjWb+R wmDQbToMjnLugIb7XR11OMT65agp2qMC9jUQ2KfrekAtadRjarf+y6NiuAn0O1G4Cj+M /IVYE1ZdnTZrJb4HQBlupDs28MDSQ2cG+jHWQcfG7HxsIWrkAAjnOHdT16FDUy8cbT8C DnSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734193238; x=1734798038; 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=fYC6LT4dL4X8l2tzCQ1hTL2Td/BaM3eFhCAaTNKigRM=; b=BygQG1355/yiBnYR5coo5Ao7H46n2s6KbW0nILwXuXZj7V1/mTX/eSw4itd/GoQVMv WH9tdyJEEMs5y+NZkIU4gfqKUISXn0sctBuPmv5WtZCdI4sipHn2CcQh6l7N6y38pU71 uIMw/nKYevv6ngu3edHsfzROc/jIIqodrUqNsgbaVNe0V9WA6vqxKcNYC/xPYpcjqTEL e6ay8N41ypUcF13xptYdTJhQti3KgWqFY9ZK3oegjs+ujqjXe56TuGYDKsPtEjnpdsdJ aK0uF1K3YVBWZ3MRhSrknk69tejzytzDolUGmKD79RVEevd1qAP49ITik3ohPERHM2JM QTJQ== X-Forwarded-Encrypted: i=1; AJvYcCU1SrA3s60PQHPpCr7NjHkZLvfieCWaaK1U/OX5t4X/vPRKabTx8Fn204m5Y5EqfYytHyh27cLSp1NM@gnu.org X-Gm-Message-State: AOJu0YxmKSwehzClwiGNrH3XnMNFfX357H4wMsbs1I+hOc4tOraFhmtl lupiRpICAKhoPhKVFNk/A7yjEkUGX0cyGllCoisBcy3uz9I95OqdD5gTNkUnVmMc7UmwMCuUoow uI/qUyaD/QgmFlNRRS50Sgq1+H68= X-Gm-Gg: ASbGncuN73T8ybygUXR9UEkmuOYZbtn2/p3tlxB3C/RU7My4ynZ93N1PezxAnD0DEVN GdECuIJumKWpPrRo9Fr/CxIRmEznGX9YCfriPEA== X-Google-Smtp-Source: AGHT+IHgEBS41OxcY7thOn4z6z/Xjy0JedL4ySGZZutx0dDycsUdD1aKxfGWtT8N0+FpFtAOpHJXrDGcF0QdJTEW9XM= X-Received: by 2002:a17:90b:3e88:b0:2ea:5054:6c49 with SMTP id 98e67ed59e1d1-2f28f8691ebmr11672229a91.0.1734193238069; Sat, 14 Dec 2024 08:20:38 -0800 (PST) In-Reply-To: <20241214171059.ogAy2D00B1Y3F3G01gAyTM@laurent.telenet-ops.be> Received-SPF: pass client-ip=2607:f8b0:4864:20::1031; envelope-from=nalaginrut@gmail.com; helo=mail-pj1-x1031.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:19987 Archived-At: > 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 w= ill > 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 y= ou 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 u= se (e.g. a > C pre-processor in case a library using macros from a FFI library, where > you don=E2=80=99t want the C pre-processor to have to stay installed when= using the > binding library), or when the compilation is messy, e.g. it uses files fr= om > the build directory that aren=E2=80=99t installed in the .scm and .go dir= ectories > (and don=E2=80=99t make sense to be installed there). > > And in the situation where all used modules are precompiled and already i= n > the load paths (e.g. modules of Guile itself, or installed with package > 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 cac= hing. > > You missed =E2=80=98-C=E2=80=99 (load-compiled-path). You can point this = to a cache if you > wish, but it doesn=E2=80=99t need to be a cache. Guile doesn=E2=80=99t ca= re about whether > it is a cache or not, as long as it has the .go, the timestamps are ok, a= nd > (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 limit= s) > and its aesthetics (it=E2=80=99s just compilation) (*), this is not a cac= he system. > > (*): for a comparison: you can compile C code to a shared and install it > in /usr/lib without /usr/lib being a cache =E2=80=93 being a cache is mor= e 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 indication= when the > =E2=80=98known cache=E2=80=99 (that thing in .cache/) is a different 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 si= ngle 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 beforehan= d 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 no= t-ready > state, but I already saved it to not loose it in case the computer needs = to > suddenly shut down=E2=80=99 and =E2=80=98latest =E2=80=98good=E2=80=99 ve= rsion 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 fi= rst .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 whe= re > 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 dependencies = 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 invoca= tion > (straightforward, but not the best option) and load a.scm (-> guile loads > 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. O= f > those two options, (3) has the least re-compilation. By these criteria, (= 3) > is the best. > > Best regards, > Maxime Devos > > >