Re: Running Compiled Guile Objects

[Nala Ginrut <nalaginrut@gmail.com>]

> 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
>
>
>