[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Running Compiled Guile Objects
From: |
Nala Ginrut |
Subject: |
Re: Running Compiled Guile Objects |
Date: |
Sun, 15 Dec 2024 01:26:54 +0900 |
> Guile doesn’t 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, right?
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 <nalaginrut@gmail.com> wrote:
> > You missed ‘-C’ (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 <maximedevos@telenet.be> 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’t see ‘more issues’ here. The (non-)issue you mention exists
>> regardless of whether module a is loaded as ‘a.scm’ or as ‘b.go’. Also
>> autocompilation causes its own issues, if it requires things in the
>> environment during compilation that aren’t available at time or use (e.g. a
>> C pre-processor in case a library using macros from a FFI library, where
>> you don’t 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 from
>> the build directory that aren’t installed in the .scm and .go directories
>> (and don’t 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 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
>> caching.
>>
>> You missed ‘-C’ (load-compiled-path). You can point this to a cache if
>> you wish, but it doesn’t need to be a cache. Guile doesn’t 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’t
>> yet), make takes care of compilation. Because of its local nature (no
>> shared cache) (^), lack of capacity limits (no time limits, no size limits)
>> and its aesthetics (it’s just compilation) (*), this is not a cache system.
>>
>> (*): for a comparison: you can compile C code to a shared and install it
>> in /usr/lib without /usr/lib being a cache – being a cache is more 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’s an indication when
>> the ‘known cache’ (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’s only a single file
>> to take care of, comprehensive is trivial).
>>
>> A third option is to use potentially outdated .go (unfortunately Guile
>> doesn’t fully separate caches from precompiled code, so beforehand you need
>> to update the timestamps to make Guile accept them). This can then be
>> separation of ‘code 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 needs to
>> suddenly shut down’ and ‘latest ‘good’ version of the code – might be
>> incomplete, but is ready for testing’. (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’t help with loading the first .go
>> (so it’s not an easier way, it’s not a way) – if a.scm sets up the load
>> paths (including compiled path), then by the time that Guile can know where
>> a.go is located, it’s too late for that. So, either you need to:
>>
>> (0) not precompile a.scm (it’s 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 ‘-C insert-go-directory-here’ to the guile invocation
>> (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.
>> Of those two options, (3) has the least re-compilation. By these criteria,
>> (3) is the best.
>>
>> Best regards,
>> Maxime Devos
>>
>>
>>
>
- Re: Running Compiled Guile Objects, (continued)
- Re: Running Compiled Guile Objects, Nala Ginrut, 2024/12/13
- Re: Running Compiled Guile Objects, Keith Wright, 2024/12/13
- Re: Running Compiled Guile Objects, Nala Ginrut, 2024/12/13
- Re: Running Compiled Guile Objects, Nala Ginrut, 2024/12/13
- RE: Running Compiled Guile Objects, Maxime Devos, 2024/12/14
- Re: Running Compiled Guile Objects, Nala Ginrut, 2024/12/14
- RE: Running Compiled Guile Objects, Maxime Devos, 2024/12/14
- Re: Running Compiled Guile Objects, Nala Ginrut, 2024/12/14
- RE: Running Compiled Guile Objects, Maxime Devos, 2024/12/14
- Re: Running Compiled Guile Objects, Nala Ginrut, 2024/12/14
- Re: Running Compiled Guile Objects,
Nala Ginrut <=
- Re: Running Compiled Guile Objects, Nala Ginrut, 2024/12/14
- RE: Running Compiled Guile Objects, Maxime Devos, 2024/12/14
- Re: Running Compiled Guile Objects, Nala Ginrut, 2024/12/14
- RE: Running Compiled Guile Objects, Maxime Devos, 2024/12/14
- Re: Running Compiled Guile Objects, Nala Ginrut, 2024/12/14
Re: Running Compiled Guile Objects, Basile Starynkevitch, 2024/12/14